►
From YouTube: OMR Compiler Architecture 20181212
Description
Meeting agenda:
* Create an issue template for new compiler IL opcode requests (#3236) [ @0xdaryl ]
* API to ask about the type a compare opcode operates on (#3302) [ @andrewcraik ]
* TR namespace usage (#3306) [ @Leonardo2718 ]
A
A
A
Okay.
So
to
kick
things
off,
I'll
talk
about
the
the
issue
template.
So
when
I
had
this
on
the
agenda
there,
there
were
still
some
open
questions
to
be
answered
about
that,
but
Charlie
Gracey
actually
added
some.
Some
comments
to
the
to
the
pull
request.
So
essentially,
what
that
pull
request
proposed
was
the
use
of
an
issue
template
for
when
a
special
issue
template
for
when
someone
wants
to
propose
a
new
aisle
opcode
and
within
that
pileup
within
that
template.
A
It
basically
provided
a
series
of
questions
that
the
the
submitter
would
have
to
answer
and
provide
justification,
and
that
sort
of
thing
I
don't
think
that
there
was
any
question
about
the
contents
of
that
form,
but
the
questions
were
really
around
the
form
in
which
it
would
be
presented.
So
the
way
that
I
thought
about
doing
it
was
with
an
issue
template,
but
you
know,
obviously,
if
another
way
of
doing
it
was
it
was
basically
just
whenever
somebody
wants
to
propose
a
new
aisle
opcode.
A
The
challenge
that
are
one
of
the
drawbacks
of
an
issue
template
where
that,
when
you
create
one
in
github,
it
actually
presents
your
issue
template
if
there
is
only
one
fairly
prominently
and
then
it
really
delegates
the
other
ones
to
be
fairly
into
a
fairly
small
link.
We
can
get
around
that
by
actually
using
creating
a
generic
issue,
template
for
any
other
issue
and
the
discussion
that
ensued
and
the
in
that
pull
request
basically
said
that
we
can
provide
much
more
information
than
we.
A
A
A
So
there's
an
example
of
that
in
the
ternary
evaluator
on
in
the
x86
code,
generator
where,
if
you
generate
a
a
ternary
that
is
evaluating
a
floating
point
condition.
So
you've
got
like
a
ternary
with
like
a
F,
compare
gue
or
something
there
like
that
under
it.
The
F
compare
gue
will
feed
itself
into
the
quality
pathway
by
answering
yes
to
is
compare
for
comparison
for
equality,
but
that
pathway
was
originally
just
testing.
Integer
type
comparison,
op
codes,
and
so
now
the
floating
point
comparison
gets
evaluated
as
an
integer
comparison
and
well.
A
So
you
can
fix
that
kind
of
problem
at
the
moment
by
going
in
and
necessarily
then
having
to
look
at
child
of
the
compare
to
know
the
kind
of
compare
that
you're
dealing
with
right.
So
all
of
the
comparisons
respond
with
integer
as
their
type
because
they
will
produce
true
or
false,
but
they
don't.
You
don't
have
a
way
in
the
opcode
properties
at
the
moment
to
ask
what
is
the
data
type
that
you
compare?
Are
you
an
integer
compare?
A
I
have
to
do
a
fairly
ugly
code
pattern
where
you
kind
of
do
is
compare
for
equality
and
go
grab
the
first
child
and
ask
its
type,
because
that
should
match
the
type
but
the
opcode
expects,
and
you
can.
You
then
make
a
rather
large
or
something
you
make
the
assumption
that
the
a
second
child
is
probably
going
to
have
the
same
type.
You
hope
and
then
proceed
with
whatever
it
was
that
you
are
planning
on
doing.
A
The
note
is
like
the
kind
of
thing
that
we're
comparing
is
sort
of
intrinsic
to
the
comparison
opcode,
so
kind
of
what
I
would
like
to
propose
is
that
we
add
a
query
that
will
let
us
ask
the
comparison
opcode,
so
the
if
compare
family,
as
well
as
the
various
compare
on
their
own
versions,
what
the
type
data
type
is
that
they
compare.
I
haven't
come
up
with
a
good
name
for
that.
A
Yet,
but
like
get
compare
data
type
or
comparison
data
type
or
something
like
that
was
kind
of
what
I
had
in
my
head
to
then
be
able
to
say:
are
you
an
integer
type,
compare
or
something
like
that,
so
that
you
could
deal
with
these
cases?
So
you
need
so
you
want
to.
You
want
the
more
general
case
where
you
ask
it
for
the
actual
data
type
that
you're,
comparing
as
opposed
to
the
question,
are
you
in
integral?
A
Are
you
comparing
integral
types
or
are
you
comparing
afloat
I'd,
be
open
to
having
both
I
think
they
both
could
be
useful
in
different
places
in
the
compiler?
Sometimes
you
are
like.
Sometimes
you
do
want
to
discriminate
between
a
double
floating
point
and
a
single
floating
point,
for
example,
but
in
other
places
yeah.
All
you
want
to
know
is
that
it's
an
integer
type,
but
if
that's
good
enough,
I
guess
I'll
be
more
of
an
more
of
a
convenience
right,
because
you
couldn't
get
the
data
tied
back
and.
A
Ask
a
second
question:
on
top
of
that
data
type
yes,
yeah
ascus
property,
whether
or
not
is
whether
it's
an
integer
or
knowlet's
so
I
mean
we
could
fold
that
detail
in
to
save
verbosity
in
the
code.
But
I
think
that
if
we
expose
something
that
says,
are
you
an
integer
type
to
compare
being
able
to
ask
specifically
what
type
of
the
compare
you
have
without
having
to
reach
into
the
child
would
seem
to
make
sense
to
me
from
the
symmetry
of
the
API.
A
The
conferral
well
and
it
also
so
so
so
yeah.
So
the
comment
was
the:
if
compares
don't,
have
a
datatype,
could
we
add
a
data
type
in
there?
Well,
yes,
you
could.
It
would
be
a
bit
of
a
corruption
of
the
meaning
of
data
type,
because
data
type
means
the
type
that
the
node
produces
and
then,
if
compare
does
not
produce
a
value,
it
is
a
treetop
that
does
control
flow.
A
D
D
The
accepted
datatype
of
children
is
specified
currently
in
the
properties
table
and
is
used
by
the
il
validator
to
make
sure
that
the
types
of
children
matches.
What
it's
supposed
to
be
so
I.
Think
that
information
in
there
and
I'm
trying
to
figure
out
whether
the
query
is
to
get
that
information
from
the
properties
table.
A
B
Like
one
of
those
top-level
questions
would
be,
do
we
I
know
that
your
use
case
came
from
wanting
to
look
at
the
pair's?
Yes,
the
question
is:
does
the
query
have
to
be
only
about
compares,
or
would
there
be
other
like?
There
are
other
nodes
that
where
you
might
want
to
ask
a
question
about
the
children.
A
B
A
D
A
A
A
A
D
E
A
E
B
C
D
D
E
A
D
C
D
That
appears.
The
resolution
was
that
everything
should
just
go
into
T
our
namespace
and
the
documentation
was
written.
That
says
this,
although
it's
worded
in
a
bit
of
a
strange
way
but
and
never
mind
that,
and
subsequently
there
seems
like
followed
discussions
and
happened
with
the
assumption
that
non
extensible
classes
going
to
TR
namespace,
then
peer
was
open
to
modify
a
class
and
one.
E
D
D
Great
yeah,
so
as
a
side
discussion
of
that
there
was
other
discussions
with
the
forum
or
project
as
a
whole
about
using
namespaces
for
the
different
components
of
the
project
and
for
the
compiler
component.
Specifically,
we
would
have
the
namespace
inside
o
lr,
o
mr
compiler,
and
the
implication
of
this
force
would
be
done.
The
decision
of
whether
or
not
extensible
classes
going
TR
Bursar's
for
mr
compiler.
D
D
There's
also
questions,
because
we're
trying
to
kind
of
move
to
this
idea
where
API
is
in
omr
are
inside
a
omr
component,
name
namespace,
and
this,
of
course
won't
work
for
extensible
classes
because
of
their
special
static
polymorphism
mechanism,
but
for
non
extensible
classes
they
really
could
live
in
the
OM
are
way
more
compiler
namespaces.
Where
would
make
sense
for
them
to
live,
but
people
have
raised
concerns
about
some
of
the
implications
this
might
have.
A
A
However,
having
that
long
prefix
on
the
start
of
many
many
many
declarations
is
going
to
make
the
code
very
much
harder
to
read,
because
you're
going
to
have
to
keep
looking
past
all
of
this
noise,
and
it
will
also
increase
I,
feel
the
tendency
for
people
to
use
auto
in
places
where
it's
not
strictly
required
and
I
worry
that
in
the
long
term,
people
doing
that
may
make
it
harder
for
us
to
do
refactorings
in
the
future.
Where
we've
done
experiments
of
the
form.
A
Okay,
change,
it
compile
see
what
broke,
because
trying
to
find
everything
is
so
difficult
and
if
Auto
allows
the
type
to
become
malleable.
You
may
not
find
the
things
that
you're
looking
for,
because
the
inference
ends
up
picking
a
different
type
that
just
sort
of
happens
to
fit
and
the
quack
method
is
there.
Although
it
may
make
it
hard.
B
A
D
B
D
Namespace
statement,
which
would
help
with
some
of
the
declarations,
not
all
it,
wouldn't
help
with
like
a
function
declaration,
unless
you
were
to
just
do
namespace
form
our
namespace
compiler
and
then
all
of
the
Texan
function,
declarations
which
is
something
we
don't
do
in
the
compiler
right
now.
You
know,
and
so
that
won't
solve
those.
But
if
say
inside
a
function
and
you
had
a
lot
of
variables
that
you
needed
to
initialize
instead
of
saying.
D
Oh
mr
Glenn,
Glenn,
compiler,
:,
:
type
name,
variable
name,
you
could
do
using
namespace
form
or
compiler
at
the
top
of
the
function,
and
then
you
would
have
access
to
everything
within
that
namespace.
So
that
would
shorten
some
of
those.
But
then
you
would.
It
would
shorten
some
of
those
variable
declarations.
But
then
you
have
to
make
sure
you
have
using
namespace
at
the
top
of
every
function.
Yeah.
A
It
would
also
make
dropping
the
code
base
harder,
because
the
usings
would
make
it
harder
to
find
the
uses.
The
other
thing
that
I'm
aware
of
having
worked
on
a
C++
compiler
in
a
past
life
is
that
not
all
C++
compilers,
you
have
the
same
semantics
with
scope
using
declarations,
some
of
them
treat
them
as
forward
declarations.
D
D
B
Selling
classes
I
like
to
me,
has
just
motivated
everything
as
unaccessible
has
to
go
to
TR
yeah,
which
I
think
is
a
simpler
consumption
model,
yeah
Emily
I
all
right,
because
anyone
who's
trying
to
consume
the
compiler
now
doesn't
have
to
figure
out
if
they
need
to
look
for
a
class
in
PR
or
an
or
more
and
the
other.
The
other
concerns
Arizona
in
the
PR
is
if
an
Omar
class
is
used
to
construct
a
TR
class,
then
it's
a
if
a
class
moves
from
being
non
extensible
and
therefore
is
concrete.
B
A
Tr
may
become
an
alias
namespace
for
Omar
compiled
in
it
like.
We
are
essentially
saying
that
giving
more
compiler
classes
that
live
in
the
TR
names
things
which
is
getting
to
what
the
way
that
it
used
to
be
many
when
it
was
closed
source
we
had
the
TR
underscore,
which
is
what
that
was
so,
in
effect,
we're.
D
B
Classrooms,
because
they
need
to
be
so,
I
was
going
to
answer
that
I
was
going
to
ask
that
question
different
consultants
in
the
world
where
Bomar
compiler
is
where
classes
live.
Where
do
the
components?
Where
does
the
Omar
layer
components
of
an
indispensable
class
right
now,
they're
in
whole
arm,
which
is
so
then.
D
D
B
Asking
a
different
question:
so,
if
so
right
now
somebody
trying
to
consume
Omar.
Looking
at
this
from
across
opponents,
the
I
know
I'm
broadening
a
question
you
on
what
you
wanted
to
consider,
but
sorry
I
think
I
have
to
do
that.
So,
if
I'm
consuming
GC
I'm
component
I'm
I'm
using
stuff,
that's
in
a
normal
colon
colon
GC
namespace,
if
I'm
using
stuff
in
the
R
as
component
I'm
using
more
water
called
:
grass
stuff.
B
So
the
natural
forgive
me
place
to
go
looking
for
compiler
stuff
would
be
an
or
mark
old,
:
compiler,
which
means
all
are
:.
:
compiler
is
kind
of
what
our
TR
is
today.
In
that
model
right
right,
there
is
no
more
TR,
we
just
renamed
it
Omar
:
:
compiler,
because
that's
where
people
should
go
to
get
compiler
classes
alright
in
I'm
not
proposing.
We
do
this
necessarily
understanding
model.
That
would
be
the
consistent
way
of
consuming
for
our
things,
but
that
means
Omar
:
:
compiler
is
TR.
B
D
D
D
B
Alright,
so
I
guess
we
both
pragmatics
and
addresses
that
issues
continue
to
use
the
TR
name
space
or
at
least
classes
that
are
extensible,
yeah
well,
I
would
say
Henry's
it
from
Omar
I
mean
I
yeah
that
helps
with
the
old,
like
the
conception
of
I'm,
going
to
introduce
my
code.
I,
don't
want
it
to
become
part
of
Omar
that
becomes
the
right,
PR
thing,
which
is
yeah
at
least
not
directly
connected
to
transportation.
B
Let
those
help
with
that
part
and
then
the
pragmatic
part
is
everything
is
TR
right
now
anyway,
so
there's
dude
make
that
happen.
So
then
D
we
still
have
that
open
question
of
our
classes.
That
are
non
extent
form.
Should
they
be
in
all
moral
TR,
which
I
guess
is
the
question.
We
started
off
with
yeah.
B
Back
to
it,
I
don't
know.
I
I
tend
to
look
at
that
from
a
consume,
ability
perspective
and
think
that
they
should
be
in
TR,
but
the
I
that
I
would
personally
agree.
It
simplifies,
like
you,
don't
have
to
think
about
where
it
is,
and
you
don't
get
burned
if
it
moves
later
like
if
it
moves
later,
it's
it
used
to
be
TR.
B
Now
it's
a
concrete
thing:
that's
in
TR
that
has
the
one
thing
in
it
right
like
you're,
still
using
a
thing
in
TR,
which
is
which
should
be
the
composed
thing,
at
least
from
an
OL
Mar
standpoint,
and
if
you
weren't
it
what
it
wasn't
an
extensible
class
before,
then
you
have
nothing
to
specialise
in
it,
you're
just
using
it,
as
is
so.
You
get
what
you
get
you
don't
as
you
get
wise
or
the
namespaces
length,
presumably
you're,
okay,
with
it
too
character.
Everything
changes
the
TR.
D
B
A
B
E
A
B
E
B
C
B
A
C
B
Would
get
rid
of
the
go
calling
shape,
or
so
some
interesting
questions
that
are
virtual
hierarchy
raises
yes,
because
then
at
that
point
the
consuming
project
has
to
be
the
one
directly
enhancing
both
a
base
class
and
the
subclasses
like,
like
a
co
generator.
For
example,
you
want
to
add
something
to
code
generator.
You
know
in
a
project,
it's
a
little
bit
hard
to
figure
out
how
the
hierarchy
fits
together.
If
you
also
have
a
like
an
x86
code,
generator
that
you,
where
you
need
to
use
your
code,
generators
extension
right.
D
D
B
D
E
D
B
D
D
D
C
D
D
C
A
B
D
Okay,
so
from
what
Mark
was
for
what
Mark
was
saying,
you
yes
he's
writing
that
you
would
still
need
something
at
the
end.
That
kind
of
is
it
becomes
the
thing
that,
and
somebody
else
is
going
to
override
the
thing
is.
We
could
really
just
turn
that
into
a
type
that,
because
the
important
thing
is
that
at
the
omr
level
we
no
longer
need
to
be
referencing,
one
that
is
provided
by
a
downstream
project.
So.
D
C
D
That
point
about
the
forward
declaration
right
now,
we
need
to
forward
declare
classes
because
we
have
to
be
able
to
afford
declare
the
thing.
That's
in
TR,
right
and
the
thing
is
what's
in
TR
can
be
either
the
thing
we
provide
or
one
that's
provided
by
a
downstream
project
that
gets
resolved
by
the
include
path
with
virtual
polymorphism.
That
needs
goes
away.
D
A
Look
like
that
when
I
buy
with
a
friend
one
I'm,
not
sure
I
buy,
he
has
a
friend
one
item,
so
the
friend
the
predominant
uses
of
friends
I
believe
far
in
but
the
the
debug
class,
which
needs
some
serious
overhaul
Ling,
but
more
on
that
later
and
then
the
other
class
that
uses
it
I
believe
is
no
in
a
note
hierarchy.
It,
like
speaking.
A
D
A
B
A
B
B
A
A
A
It's
really
to
provide
some
clarity
around
the
text
that
we
currently
have,
because
the
guidance
that
we
given
Wendy
you
sit
here
named
face
because
it
someone
who
is
not
familiar
with
the
project
like
many
of
us
are,
did
come
across
an
issue
where
he
needed
to
decide
where
to
put
the
class
that
he
was
working
on
in
this
case
was
registered
at
dinner
and
based
on
the
guidance
that
we
have
documented.
It's
it's
it's
in
the
tRNA
space,
but
clearly
there's
some
mattered
differences
of
opinions
on
where
things
should
go.
So
it
was
really.
E
A
B
B
B
A
J9Z
memory,
reference
class
to
rise
so
j9,
the
j9z
namespace,
derives
directly
from
the
Omar
Z
namespace,
so
it
skips
over
of
the
usual
connection
mechanism,
but
it
the
reason
it
does
that
you're
likely
an
acceptable
class,
even
though
it
is
yes,
I
believe
the
reason
it
does.
That
is
because
j9z
wants
to
skip
over
the
j9.
A
E
B
B
B
B
A
E
B
B
E
B
D
D
E
A
D
E
B
A
A
E
E
A
Mean
looking
at
the
future,
if
we
don't
know,
we
can
rely
on
the
future
of
extensive
I
mean
as
far
as
you
have.
We
can't
look
into
a
crystal
ball
and
predict
that
we're
going
to
get
rid
of
extensible
classes
at
some
point,
because
I
think
that
is
very
much
a
long-term
thing.
If
it
does
happen
like
we're
on
the
we're
looking
at
years.
B
A
B
Certainly,
but
trying
to
minimize
that,
so
it's
not
like
he's
it
an
old
one
place
now
you
have
to
do
it
in
more
overt
kinds
of
different
places
or
or
you
were
doing
it
this
way
and
then
we
said
no
do
it
that
way,
and
then
we
change
extensibility.
It's
like
okay
go
back
to
the
way
you
were
doing
it
before.
B
To
me,
it
feels
like
another
thing:
solidifying
on
the
tRNAs
basis,
the
easiest
consume
ability
model
going
forward,
and
even
if
we
are
going
to
migrate,
people
away
from
the
current
solution
to
a
different
type
of
extensibility,
having
everything
coming
from
one
place
makes
it
easier
to
describe
what
going
forward
that
I
posed
it.
If
you
have
one
of
these
than
do
that,
or
if
you
have
one
of
these,
do
that
or
if
you
did
one
of
these
crazy
eat,
seven
things
you'll
figure
it
out
until
I'll.
E
E
D
A
B
The
curators
down
write
it
in
the
context
of
that
I
mean
I,
know
it's
a
complicated
discussion
that
we
had
here
but
like
if
the
grander
story
is
right,
then
right,
even
though
a
grander
story
we're
trying
to
move
the
grander,
let
the
bigger
story
to
work
out
a
more
consistent
story
with
the
rest
of
Omar
and
simpler
model.
We
need
to
get
everybody
to
a
consistent
place,
first,
yep
right
because
a
that
things
are
not
going
to
be
decided
for
a
while.
That's
a
research
project
and
what's
pushing
forward
on
it.