►
From YouTube: OMR Architecture Meeting 20210429
Description
Agenda:
* Revisit: Clean up centralized opcode enums (#5703) [ @fjeremic ]
A
B
I
guess,
pre-processor
tricks
that
we're
doing
at
the
moment
I
have,
and
another
part
of
reason
was
that
our
evaluator
names
are
kind
of
all
over
the
place
on
different
cogents.
I
think
I
gave
an
example
last
time
of
the
long
unsigned
negative
evaluator
having
you
know,
different
name
on
every
single
platform.
B
So
what
I
did
was
er,
I
guess
late
last
year
I
prototyped
how
this
would
look
on
x86
just
to
get
an
example,
and
one
of
the
concerns
we
had
at
the
time
was
the
footprint
growth
which
I
measured
to
be
about
0.7
using
openg9
as
an
example
and
that's
for
every
single
evaluator.
I
think
since
then,
we've
eliminated
some
up
codes
and
there's
more
coming
with
the
dfb
deprecation
as
well.
B
B
I
guess
not
sure
what
to
call
this.
It's
still
kind
of
a
hack
to
let
our
downstream
projects
override
things.
So
I
I
have
the
two
pr's
open
just
to
give
you
a
sense
of
what
this
looks
like
it's
a
really
mechanical
change,
but
it
does
introduce
quite
a
bit
of
code
so
today
or
for
x86.
I
just
made
the
change
here.
So
what
we
have
today
is
we
have
all
of
these
preprocessor
defines,
for
example,
an
acounts
evaluator.
B
The
unfortunate
side
effect
of
this
is
that
you
can't
actually
override
evaluators
in
downstream
projects,
because
you'll
have
an
aiming
clash
because,
for
example,
if
I
want
to
override
the
white
swap
evaluator
well,
it's
already
defined
in
omr,
and
it's
going
to
go
here,
no
matter
what.
So.
I
can't
actually
override
that
in
a
nice
way
at
the
moment.
So
what
I
guess
the
current
proposal
that
we
have
introduces
quite
a
lot
of
boilerplate.
B
So,
rather
than
doing
those
underscore
methods,
we
just
implement
all
the
functions
evaluators
with
just
the
op
code
and
then
evaluator
in
the
name
and
then
literally
all
of
these
just
are
just
stubs,
calling
whatever
was
on
the
right
hand,
side
of
those
processor
defines
so,
for
example,
the
lmax
evaluator
today,
and
the
processor
stub
is
calling
the
min
max
evaluator
function
and
in
the
new
world
we
just
have
a
sub
function,
calling
the
same
thing.
So
it's
just
a
knock
change
effectively.
B
Of
course,
over
time,
we'd
probably
want
to
merge
things
like
this
into
the
actual
lmax
evaluator.
If
that
makes
sense,
and
most
of
the
time
it
actually
does,
unless
we
share
a
lot
of
the
code
for
each
and
every
evaluator
and
on
the
openg9
side,
how
this
looks
is
we
actually
get
rid
of
the
entire
tree
evaluator
table?
So
these
are
no
longer
needed
anywhere
in
openg9
and
for
the
upcodes
that
are
defined
in
openg9.
B
B
So
I
guess
the
revisit
portion
of
these
is
just
to
get
people
looking
at
the
two
pr's
and
we
can
make
a
call
on
whether
we
actually
want
to
proceed
with
this,
or
should
we
just
re-implement
our
hash
defines
to
be
able
to
override
these
evaluators
at
compile
time,
maybe
as
a
stepping
stone,
maybe
sometime
in
the
future.
We
can
take
a
look
at
doing
the
whole
thing.
B
B
A
B
B
C
It
could
be
a
lot
less
code
introduced.
If
the
you
know
any
of
that
single
use,
inlining
is
done
or
you
know,
I
guess
you
could
think
of
it.
As
for
a
function.
That's
only
used
for
one
op
code
just
renaming
the
function
instead
of
introducing
a
wrapper
that
might
already
drastically
reduce
the
amount
of
additional
code.
B
C
A
Yeah,
that's
a
nice
feature
for
sure
and,
as
philip
mentioned,
there
has
been
some
work
happening
lately
to
reduce
the
size
of
the
ilop
code
table
in
the
first
place.
So
at
least
driven
from
the
open,
j9
side
phillips
been
removing
a
lot
of
the
the
the
the
decimal
code
there.
It's
not
going
to
impact
omar
too
much,
but
there
will
be
some
things
spilling
over
and
then
all
the
up
codes
that
I
talked
about
two
weeks
ago.