►
From YouTube: OMR Compiler Architecture Meeting 20190912
Description
Agenda:
* Operational changes for Compiler Architecture Meeting [ @0xdaryl ]
* Contribution of LLJB to OMR [ @nbhuiyan ] (#4292)
A
Okay,
welcome
everyone
to
this
week's
compiler
architecture.
Meeting
it's
been
a
couple
months
since
we've
since
your
last
time
a
bit
of
a
bit
of
a
small
summer,
but
we
want
to
get
things
back
on
track
today.
There's
a
couple
of
topics
I
would
like
to
discuss.
The
first
is
some
changes
that
I'd
like
to
propose
for
the
focus
of
of
these
meetings
going
forward,
and
the
second
is
a
is
a
project
that
that
one
of
the
interns
at
IBM
has
been
working
on
for
the
past
couple
of
months
to
consume
LOV
Mir
in
NMR.
A
So
we
were
talking
through
what
needs
to
happen
in
order
to
make
that
contribution
to
to
Omar,
but
to
begin
with,
I'd
like
to
talk
about
the
focus
of
this
meeting
going
forward,
so
I'd
like
to
change
the
focus
I
like
to
broaden
the
focus
to
to
be
beyond
just
the
compiler
architecture.
There
are
things
that
we
talked
about
in
this
meeting
that
have
that
that
reach
beyond
just
the
compiler
into
other
aspects
of
omr,
so
I
think
I'd
like
to
to
change
the
focus
of
this
to
really
be
an
overall
boom.
A
Our
architecture
call
and
trying
to
get
participants
from
other
components
within
the
Omar
package
to
to
bring
up
topics
and
feel
free
to
discuss
them
in
instead
of
regular
forum
if
they
wish.
So
it's
a
relatively
small
change,
I,
don't
think
I'm
going
to
be.
You
know,
creating
different
issues
and
like
different
schedules
and
all
that
I
think
it's
really
just
going
to
be
from
this
point
forward.
All
of
invite
non
compiler
topics
as
well,
but
omar,
focused
to
be
discussed
here
and.
B
B
So
there
are
a
few
things
that
I
think
we
need
to
be.
We
need
to
discuss
a
firstly
proper
weight.
You
know
whether
there
are
any
concerns
about
having
such
a
project
in
Oman,
and
then
we
have
to
discuss
issues
about
whether
there
is
any
like
what
was
a
more
appropriate
directory
structure
of
such
a
project
living
within
Lamar.
B
So
it
could
be
in
the
credit
that
way,
and
it
introduces
a
number
of
build
appendices
built
some
dependencies
on
one
more
project,
but
and
what
I'm
thinking
up
is
to
have
LGB
as
an
optional
tool
that
is
built,
if
only
if
you
specify
it,
it
doesn't
have
to
be
built
with
everything.
So
any
of
the
dependencies
that
are
going
to
be
introduced
as
a
result
of
this
will
also
be
optional.
B
B
D
B
A
B
B
The
dependences
are,
we
use
clang
8.0,
because
right
now,
all
of
all
of
our
well
ir
is
generated
from
C++
and
we
use
a
plan
of
8.0
as
the
front-end
compiler
for
generating
dir
and
then
you
can
obviously
add
different,
like
other
grunt
compiler
friends
as
well
to
a
generate
LLVM
ir.
But
right
now
we're
going
to
use
that
and
then
we
also
use
the
alluvium
developer
libraries
and
that
requires
a
low
vm
8.0.
B
So
yeah
these
are
the
new
requirements.
We
already
do
have
a
library
dependency
for
the
Walmart
checker
in
Travis.
Yet
those
I
believe
where
we
use
LVM,
3.0,
5
or
6,
or
something
like
that
so
for
Travis
here
I
think
it
will
be
possible
to
even
upgrade
our
or
Mar
checker
to
so
that
we
can
actually
use
LLVM
8.0
for
both
loj
B,
as
well
as
Walmart
checker.
B
C
B
Yeah,
so
when
you
will
do
when
you
install
the
yellow
p.m.
developer
libraries,
you
get
the
header
files
under
and
which,
when
we
finally
pass
through
this
header
files
in
their
configuration.
So
that's
not
something
you'll
have
to
worry
about.
As
long
as
you
have
LLVM
developer.
Libraries
installed.
D
B
B
Yeah
so
that'll
be
I,
think
that's
something
that
we
that
will
be
very
useful,
but
then
the
reason
I
was
like
I
haven't
really
like
I'm,
not
saying
that
you
know
we
should
be
labeling
it
all.
The
time
is
because
I'm
just
concerned
about
any
concerns
that
are
coming
from
having
to
change
the
build
environment
of
the
PR
machines.
So
the
thing
is:
if
we
do
want
to
have
it
there,
then
well,
it
will
be
in
there.
C
B
So,
like
I
mentioned
earlier,
I
want
to
see
ljb
as
a
tool
that
you
can.
That
provides
an
easier
interface
to
jet
filter
itself,
for
languages
that
generate
LB,
Mir
so
and
because
LVM
ir
is
sorry
because
l
jb
is
using
j
builder
for
for
everything
I
felt.
Perhaps
it
will
be
more
appropriate
to
view
it
as
as
a
sub-project
of
Tipler.
B
There
really
isn't
a
more
argument
than
that,
and
I
don't
know
if
you
know
it's
really
necessary
to
have
another
subdirectory
in
the
top
level,
at
warm
our
directory
structure
for
l
JD
project,
because
yeah
well
we're
just
having
we
have
another
way
to
consume
the
omar
compiler
other
than
jet
builder.
At
the
top
level.
C
B
B
D
Would
argue
in
favor
this
yeah,
you
know
supporting
this
conclusion.
I
mean
in
principle,
is
just
a
different
kind
of
method.
Builder
right,
yeah
takes
a
take.
Something
kind
of
like
bunk
builder,
has
a
different
API
for
how
func
builder
uses
method
builder.
This
is
just
another
API
built
on
top
of
mythical
derp
that
happens
to
take
an
LLVM
function
as
its
input
to
drive
the
method
builder.
D
D
B
D
D
B
D
C
D
A
A
In
your
in
your
repo
right
now
is
there
anything
other
than
the
source
code
and
the
test
cases?
Are
there
tools
or
documentation
or
anything
else
you
have
in
there?
That
would
have
to
find
a
home
somewhere
in
in
in
Omar,
or
do
you
have
any
sort
of
special
build
requirements
other
than
the
dependency
of
no
avail.
B
No
and
as
for
documentation,
I
just
a
readme
file
right
now
and
I
like
I,
am
writing
up.
I
have
already
begun
writing
up
the
documentation
that
I
planned
doing
code
within,
like
underdogs
of
like
Walmart,
documentation,
directory
and
that'll
be
a
part
of
the
initial
pull
request
to
contributing
ljv.
Okay.
A
B
D
B
D
B
D
B
B
B
C
B
D
B
D
A
B
A
B
A
B
A
B
B
D
B
B
D
D
B
The
thing
is,
there
are
a
few
classes
that
will
cause
conflict
with
within
laconically
which
we
use.
Typically,
if
there's
going
to
be
some
naming
conflicts
for
the
con
classes,
which
is
what
I
was
thinking
of
having
another
namespace
for
the
topic
for
the
classes
in
hello,
GP
and
yeah,
so
I
think
AB
is
something
you
can
discuss
once
I
open
the
PR-
and
you
know
everyone
can
take
a
look
at
how
this
is
going
to
be.
A
D
Rick
well
so
the
downside
of
approach
that
you
described
is
that
we
may
ask
it's
possible
that
we'll
ask
you
to
make
substantial
changes
to
how
the
code
is
organized.
If
you
show
us
something
and
we
end
up
not
liking
it
supposed
to
discussing
it
up,
front
I'm,
okay
with
it
as
long
as
you
understand
that
does
it
seem
like
it
would
be
like
dramatic
refactorings
would
be
required
anyway.
So
maybe
it's
not
too
painful
to
do
it
that
way.
B
B
B
B
D
D
D
D
B
A
B
Know
I
was
thinking
end
up
like
by
the
beginning
of
December,
simply
because
they're
like
I,
want
to
there's
a
lot
of
things.
I
have
to
plan
for
ll
JB
and
a
lot
before
it
gets
contributed.
I
want
it
to
be
closer
to
that
state,
and
so
that
you
know
once
it
goes
into
or
mark
it
doesn't
have
to
have
frequently
make
frequent
pull
requests.
Just
to
add
a
few
like
features
to
it.
Okay,.