►
From YouTube: OMR Architecture Meeting 20190926
Description
Agenda:
* OMR release candidate 0.1.0 [ @mstoodle ] (#4338)
* Rename compiler processor directories [ @0xdaryl ] (#4299)
* Remove TR::imulover IL opcode [ @Leonardo2718 ] (#4351)
* Rename TR::Xternary IL opcodes to TR::Xselect [ @0xdaryl ] (#681)
A
A
Okay,
welcome
everyone
to
this
week's
OMR
architecture.
Meeting
we
have
four
items
on
the
agenda
today:
I
need
to
deviate
a
little
bit
from
the
ordering
in
the
that's
already
been
posted
and
just
to
accommodate
some
schedules.
So
the
first
one
that
we're
going
to
be
talking
about
today
is
a
is
a
compiler
request.
So
it's
issue
number
for
$2.99.
A
A
In
discussions
with
some
of
the
people
wanting
to
contribute
risk,
5
code
became
clear
that
the
choices
of
those
names
isn't
necessarily
standard
and
it's
actually
influencing
the
choice
that
others
want
to
give
to
directory
names
as
well.
So
to
be,
we
just
decided
that
what
we'd
like
to
try
to
do
is
to
rename
those
to
more
common
names,
such
as
x86
power,
Z
in
Z's,
appropriate
RMA
or
64,
and
risk
5
for
risk
5.
So
it's
really
being
consistent
and
its
really
being
fair
across
the
across
the
board.
A
So
there
was
a
bit
of
discussion
in
for
$2.99
already
I,
don't
think
I
heard
any
real
objections
to
the
to
the
proposal.
I
think
the
one
outstanding
one
is
we're.
One
open
issue
is
what
to
do
with
the
power
directory
or
a
couple
of
different
choices
there
and
personally
I
like
to
go
with
power,
because
it
is
the
most
correct
thing
to,
but
PPC
tends
to
be
the
more
what
everyone
will
actually
understand,
but
I
personally
prefer
power.
A
Others
have
expressed
interest
in
that
as
well,
so
it
may
stop
there
for
a
moment
and
watch
it.
Let
me
just
say
that
any
work
that
we
do
here
is
going
to
have
an
impact
on
downstream
projects,
because
the
naming
of
those
directories
is
important
for
the
the
way
that
the
extensible
classes
actually
work
so
and
unfortunately,
this
isn't
something
that
may
be
able.
We
may
be
able
to
do
in
stages
unless
it's
really
ugly,
which
I
don't
really
want
to
do
either.
A
B
A
Ideally,
they
should
agree
to
the
same
naming
scheme
so
like
open
j9
has
directories
with
these
names,
for
example.
We
would
well
need
them
to
adopt
these
names.
Well,
yeah
I
mean
I,
don't
I
mean
if
it's
more
of
a
consumption
of
alomar
like
a
requirement
from
the
consumption
of
Olimar
right,
it's
it's
to
make
the
extensible
classes,
work
and
open
j9
as
well.
So.
A
A
A
B
Legacy
opcode
was
discovered,
called
I'm
all
over
and
as
far
as
I
can
tell
from
the
tiny
bit
of
code,
that's
written
and
the
compiler
to
support
it.
The
swinging,
the
power
cogent.
If
there's
an
evaluator
for
it
and
one
comment,
it
seems
to
be
essentially
trying
to
do
what
we
would
now
use
an
overflow
check.
For
so
it
tries
to
do
a
multiplication
and
see
the
fit
overflows.
B
All
the
code,
generators
right
now,
except
power,
have
it
as
onion
an
implemented
op
evaluator.
I
looking
at
the
code
for
the
power
code
generator.
I
think
that
it's
not
handling
every
case
and
things
could
break
horribly
because
it
tries
to
detect
whether
the
children
are
signed
or
unsigned,
but
it
doesn't
cover
every
days
and
then
unsigned
all
codes
are
some
of
them
are
being
deprecated.
A
A
B
A
A
That's
a
little
bit
lesson
to
us
so,
and
these
are
the
request
was
to
rename
it
to
a
select
family
of
op
codes.
This
problem
came
about
because
of
it.
So
first
of
all,
this
issue
has
been
open
for
at
least
a
couple
of
years
now,
and
it
came
about
from
from
some
people
working
in
the
code
and
the
confusion
around
the
semantics
of
the
ternary
aisle
opcode.
A
Part
of
that
is
the
fault
of
the
project,
in
that
we
don't
actually
have
great
documentation,
explicit
documentation
on
the
semantics
of
these
various
opcodes,
but
but
and
as
a
result
of
that,
people
were
bringing
in
some
of
their
preconceived
conceptions
about
how
those
opcodes
were
supposed
to
behave.
So,
for
example,
in
the
case
of
the
ternary.
A
A
So
for
the
semantics
of
that
OP
code,
the
the
general
problem
of
documenting
RI,
RI
L,
still
needs
to
get
solved,
but
I'd
like
to
find,
as
part
of
this
PR
at
least
to
find
someplace
to
hang
at
least
a
description
of
what
the
semantics
of
the
select
op
codes
are
going
to
be
just
so
that
there
is
something
there
we're
not
thinking
as
ambiguous.
So
any
discussion
on
that.
A
So,
unlike
the
previous
two
topics
that
we
just
discussed,
I
think
that
we
can
actually
get
away
with
not
breaking
any
downstream
projects
by
renaming
things,
because
I
think
that
we
can,
we
can
stage
things
by
simply
creating
an
alias
too,
because
it's
really
just
an
entry
and
enumeration
that
we're
creating.
We
can
actually
create
a
select
opcode
that
aliases
to
the
corresponding
ternary
off
code
added
muammar
makes
a
change
downstream,
come
back
to
omar
and
make
the
change
so
I
think
that
we
can.
We
can
get
away
with
not
breaking
things
eh.
A
Okay,
so
I'll
add
a
comment
into
that
issue.
If
there's
another
discussion
too,
to
let
the
there
is
a
developer
that
is
interested
in
working
on
this,
so
I'm
going
to
just
let
him
know
what
what
we've
decided
here
so
that
he
can
do
the
right
thing
and
going
forward
he's
probably
gonna
need
a
little
bit
help
defining
the
semantics
of
it.
Obviously,
because
I
don't
think
if
we
collectively
put
our
heads
together
here,
we'd
have
a
hard
time
coming
up.
A
C
C
I
don't
know
I
mean
we're
not
we're
all
on
the
cusp
of
creating
a
stable
API,
first,
any
of
the
components
right
now.
So
it's
not
like
it's
and
urgently
needed
them
release
for
anybody
if
the
components
that
are
out
stable,
api's
have
stable
IP
is
the
components
that
don't
have
stable,
API,
they're,
probably
going
to
continue
to
have
unstable
api's
for
the
time
to
be
I.
C
Yep,
that's
one
of
the
other
topics,
and
one
of
the
other
issues
is
creating
kind
of
release
notes
for
their
release
to
describe
you
know
what
the
state
of
the
world
is.
Most
of
these
things
were
actually
written
down
in
the
release
plan
that
was
approved
without
any
comments
through
the
Eclipse
process.
C
No
opinions
all
right
so
given
that
I
would
probably
just
pick
the
ones
that
open
genuine
picked,
because
then
we
can
at
least
see
that
we
have
a
consumer
of
that
release.
Even
if
they
didn't
consume
it
consciously
hum
and
they
don't
have
any.
We
don't
have
any
agreement
with
the
open,
Genome
Project
to
continue
to
have
them
pick
up
releases
but
I
think
it's
a
reasonable
place
for
us
to
start.
Given
that
we
don't
have
any,
you
know
critical
need
to
to.
E
C
C
C
Okay,
in
that
case,
I
guess
it's
just
kind
of
there's
a
few
pieces
of
work
that
then
have
to
flow
downstream
from
doing
that
and
I.
Think
most
of
them
are
things
that
committers
can
do
they're,
not
things
that
leads
have
to
do,
although
some
of
them
might
be
so
I
guess
we
also
have
to
decide
if
we
want
to
create
a
github
release.
C
That's
associated
with
this
I
had
the
notion
of
at
least
creating
a
live
jet
builder
TG
said
like
the
thing
that
wraps
up
the
library
plus
the
include
dur
trees.
Both
the
code
samples
with
a
readme,
which
kind
of
the
release
thing
that
I,
created
frigate
builder
back
in
the
day,
is
when
we
didn't
have
an
open
source
compiler
that
it
was
based
upon
as
kind
of
a
one
binary
thing
that
we
could
produce
as
part
of
an
home
our
release
so
I'll.
C
C
C
C
The
there
is
also
another
question
is:
is
there
any
additional
testing
that
we
can
or
should
perform
for
the
release
ahead
of
doing
a
release
with
vanishing
small
amount
of
time
to
do
that
and
if
we're
choosing
this
based
on
an
open,
j9
commit
I'm,
not
sure
what
that
look
value,
that
additional
testing
would
provide
unless
it
just
happened
to
work
there,
any
testing
that
we're
not
running.
Yes,
exactly,
that's
the
main
challenge
that
I
have
with
the
whole
like
what
else
would
we
do
I
think
in
future?
C
It
would
make
sense
for
some
of
the
prototype
projects
that
we've
got
right,
so
all
of
those
just
build
their
pilots
and
the
salm.
For
example,
once
we,
if
we
can
create
a
milestone
build
earlier
than
one
week
before
we're
doing
the
release,
I
think
it
would
be
valuable
for
having
those
projecting
those
projects
if
they
have
the
time
to
run
the
project
like
they're
like
the
Lua
one
could
run
Lua
tests
on
it
to
make
sure
nothing
broke.
C
D
D
There
are
some
PC
performance
tests
that
I
want
to
get
back
up
and
running
that
I
want
this
at
least
taking
a
point
of,
and
also
the
code
coverage.
So
we
had
originally
run
code
coverage
on
all
of
our
tests.
I
know
for
from
budget
perspective
that
isn't
very
important,
but
I
still
would
like
to
be
able
to
measure
that
as
go
forward
with
the
room.
So
having
said
that,
I
don't
have
that
stuff
ready
for
this
release,
but
I
will
be.
C
C
A
C
C
A
E
E
A
A
C
E
I
think
our
process
so
far
has
been
that
as
long
as
we
can
get
the
change,
we
need
into
om
our
master.
We're
happy
to
pull
it
into
our
release.
Branch
into
the
open,
j9
release,
branch,
I'm,
not
sure
adding
the
extra
release
branch
dependencies
is.
It
feels
like
an
extra
complication
in
our
process.
You
know
if
that
lines
up
completely
and
cleanly
for
all
the
things
we
need
great
move.
C
A
C
C
Well,
why
don't
we
just
do
that
and
because
I
don't
think
we
need,
we
don't
need
to
go
as
I
understand
it.
The
verify
this
with
a
cliff,
but
we
don't
have
to
go
through
another
release
plan
to
do
a
dot
dot
one
release.
So
if
there's
additional
fixes
that
it
makes
sense
to
go
on
tour,
got
one
release
we'll
put
them
on
there
just
like
we
would
for
any
other
problem
report
that
going
I
guess
in
principle.
C
A
The
amount
of
testing
of
some
of
the
areas
of
the
infrastructure
in
Omar
is
likely
to
be
higher
in
some
of
those
derivative
projects
because
they'll
hammer
on
different
parts
of
the
framework
they
may
find
other
issues
they
may
require
those
to
be
fixed
for
their
particular
release
or
they'll.
Do
a
revision
release
if
they
find
them,
bundling
them
into
a
six
pack,
essentially
on
the
end
of
it.
C
B
C
Something
that
a
lot
of
these
things
will
depend
on
how
what
our
release
cadence
ends
up
being,
which
we
haven't
discussed
and
I.
Don't
want
to
discuss
this
part
of
this
I
just
want
to
get
this
release
out
the
door,
and
then
we
can
start
discussing
topics
like
how
often
are
we
going
to
do
this,
which
will
impact?
You
know
how
costly
it
is
and
how
dangerous
it
is
for
people
to
put
fixes
on
to
that
police
branch
afterwards
and
technically,
we
only
have
one
official.
C
Actually,
the
country
we
have
more
than
one
consumer
of
this
tech,
but
that
other
consumer
is
Debbie
endows
who's.
The
one
who
asked
us
to
base
on
the
same
commits
that
opened
Jennings,
you
think
so.
I
won't
put
words
in
his
mouth,
but
I
think
he
would
be
in
favor
of
us
doing
what
we're
talking
about
here.
C
B
G
C
C
C
C
B
C
Information
about
the
release
right,
nobody
wants
to
know.
What's
in
the
release,
they
should
go
to
the
release
and
it
should
describe
faithfully
what's
in
there,
which
I
think
again,
most
of
that's
probably
described
already
in
the
release
plan
yeah
put
together
on
intending
to
substantially
lift
from
that
document.
C
C
G
G
A
C
A
C
A
C
One
this
one
because,
because
it
was
of
you,
know
three
years
into
the
project,
it
didn't
make
sense
to
create
a
document
to
plan
all
the
things
that
we
are
going
to
do
starting
three
years
ago
going
forwards.
I
think
it
makes
a
lot
more
sense
to
be
a
little
more
proactive
and
talking
about
what
we
think
is
going
to
happen
and
for
the
next
release,
one
part
of
which
is
deciding
when
the
next
release
is
likely
to
be
or
is,
should
be
like.
Are
we
going
to
do
time
box
releases?
C
Yeah,
we
spent
a
whole
weekend
worth
of
content
to
look
anyway,
so
yeah
so
fold.
Those
kinds
of
issues
I
think
we
should
start
discussing
as
soon
as
we
get
this
one
out
the
door
right
so
I
think
creating
an
issue
for
the
next
release,
planning
which
we
should
start
off
with
some
of
these
other
topics.
And
then
we
can
come
back
to
this
meeting
in
a
couple
of
weeks.
Will
it's
done
the
release
by
then,
and
we
can
kick
off
that
discussion?
I,
guess,
I'm.