►
From YouTube: OMR Architecture Meeting 20210513
Description
Agenda:
* Revisit: Clean up centralized opcode enums (#5703) [ @fjeremic ]
* Prune vector IL opcodes (#6003) [ @0xdaryl ]
A
A
C
A
Okay,
I
don't
want
to
I'll.
Let
him
speak
in
the
issue,
but
I
think
he'll
be
okay.
With
a
point
seven
percent
increase
myself,
I
mean
the
feedback
that
I
would
have
is
I'm
I
mean
it's.
It's
moving
us
forward
in
a
in
a
direction
that
I
think
that
we
want
to
move
into.
So
I'm
in
the
absence
of
any
better
solutions.
I'm
I'm
I'm
fine
with
with
going
ahead
with
that.
A
B
B
So
we
do
have
the
option
of
just
going
to
if
deaf
route,
which
will
enable
us
to
override
evaluators,
we
won't
have
the
canonicalization
of
names
or
things
like
that,
but
we
could
do
it
in
a
two-step
process,
where
first
we
let
the
overrides
happen.
We
can
do
our
downstream
improvements
in
opengni,
for
example,
and
then,
as
a
second
step,
we
could
change
the
names
like
we
have
it
today.
B
A
B
B
B
A
B
B
A
A
A
C
A
A
A
There
has
been
various
vector
implementations
in
omr
over
the
years
or
what
you
see
in
omr
over
the
years.
This
has
been
driven
by
a
variety
of
different
things,
and
if
you
look
at
the
op
codes
that
that
we
have
there's
109
of
them
at
least
there
is
a
fairly
incomplete
set
of
implementation
for
these
various
ilop
codes.
A
A
A
And,
of
course,
these
days
vector
lengths
are
128,
512
256.,
there's
proposals
in
the
works
for
our
for
future
architectures
as
well
that
go
up
to
2048
bits
as
well.
So
you
know
it's
it's
it's
it's
grown
past
what
we
are
able
to
handle
with
the
with
the
way
that
we
represent
vectors
in
in
omr.
So
so
clearly,
some
some
rethinking
needs
to
happen
here
and
gita
is
sort
of
on
the
forefront
of
thinking
about
how
to
re-represent
the
vector
operations
in
in
il.
A
If
you
go
back
and
look
at
the
history,
it's
one
of
the
first
ones
that
we
have
and
actually
gita
came
to
that
meeting,
then
and
and
put
forth
a
proposal
for
for
adding
vector
lengths,
different
vector
lengths
to
the
to
the
il
op
codes.
I
suspect
that
well
one
of
the
outcomes
of
that
was.
We
came
up
with
a
proposal
or
a
set
of
ideas.
A
We
were
going
to
go
away
and
write
up
a
proposal
and
then
come
back
to
the
group
with
a
with
that
proposal
to
get
to
get
approved.
We're
kind
of
at
that
state
right
now,
where
it's
likely
someone
like
is
going
to
come
back
with
a
with
a
new
proposal
for
for
vector
aisle
op
codes,
but
in
thinking
about
how
that
should
be
designed
it.
A
Sorry
for
this
particular
for
this
particular
issue:
do
you
see
my
browser
yep
yep?
Okay,
so
what
I've
discovered
was
that
there's
about
27
op
codes
that
we
actually
do
use
and
then
there's
a
whole
bunch
that
we
don't
I'll
just
skip
over
this
one
for
a
sec,
but
there's
a
whole
pile
here
that
we
that
we
don't
seem
to
have
any
use
for
the
the
semantics
aren't
necessarily
clear
what
they
do.
There's
incomplete
implementations
for
for
some
of
these
as
well.
A
A
So
the
fact
that
so
with
that
notion,
I
I
think
that
many
of
these
should
be
considered
for
for
for
removal
and
again,
like
some
of
the
other
iop
codes
that
we
had
removed
in
in
in
recent
memory
here.
The
advantage
of
removing
them
is
that,
if
somebody
does
come
up
with
a
use
case
for
these
in
the
future,
when
they
do
come
back
with
a
use
case,
they
should
come
with
documentation.
They
should
come
with
trill
tests
to
exercise
them
and
and
all
those
good
good
sorts
of
things.
A
So
if
we
ever
do
need
an
implementation
of
these,
obviously
the
code
is
still
there
in
git,
so
we're
not
losing
anything
here,
but
it's
really
just
an
attempt
to
get
that
109
up
codes
down
to
a
much
more
manageable
set
that
we
can
that
we
can
reason
about.
So
what
I
was
hoping
was
that
you
know
people
could
review
this
list
that
I
have
here
to
see
whether
or
not
there's
anything
that
well.
A
Oh
sorry,
if
we're
looking
at
families
of
that
include
element,
size,
sorry,
different
element
types.
I
think
these
bunch
down
here
will
actually
fall
into
some
of
the
comparison
ones
up
up
here
so
like
right
now
we
have
these
sort
of
generic
vector.
Compare
equal,
not
equal.
That
kind
of
thing,
but
if
we
start
adding
ones
for
integers
bytes
doubles
floats
that
kind
of
thing
these
ones
would
just
sort
of
naturally
get
represented
in
in
in
that,
so
it
may
be
worth
saving
these.
A
I
also
have
the
max
and
the
min
up
codes
on
here.
These
are
more
for
symmetry,
with
non-vector
op
codes
as
well.
I'm
not
sure
if
we
should
keep
them,
but
I
have
them
in
this
list
right
now
for
now
and
the
list
that
we
do
have
that.
I
think
that
we
should
keep.
It
is
consists
of
basically
the
the
the
arithmetic
operations:
it's
got:
data
movement,
op
codes
and
comparison,
op
codes
and,
of
course,
the
the
register
ones.
A
There
are
vector
specific
ones
like
get
element
and
set
elements
and
splats
that
kind
of
thing
those
are
here
be
mainly
because
not
because
they
are
they're
here,
because
we
are
using
them
in
some
capacity
in
in
either
the
spindizer
or
the
escape
analysis
is
even
using
these
the
simplifiers
introducing
these
so
rather
than
think
through
all
those
cases
and
whether
or
not
they're
actually
needed.
I
just
kept
them
on
this
list
for
now.
C
So
I
can
imagine
what
what
v
compare
eq
and
ne
might
be
without
a
particular
element
size,
but
I
don't
know
about
the
ordering
comparisons.
I
think
usually
the
the
the
typical
comparison
that
you're
going
to
apply
to
vectors
is
going
to
be
element
wise
with
a
sort
of
vector
of
results.
Right
eq,
any
you
can
you
can
easily
imagine
okay,
well
we're
going
to
check
if
the
entire
thing
is
equal,
but
what
what
does
less
than
mean?
Is
it
lexicographic?
A
So
you're
referring
to
like
these
four
here
yeah,
so
without
without
an
element
type.
So
unlike
what
these
have
that
were
they're
specifically
for
integers
or
doubles
right,
okay,
you're,
maybe
right
there
see
how
we're
actually
implementing
those
in
the
in
the
back
ends
that
do
to
see
what
operation
they're
mapping
to
you're
right
unless
the
data
type
is
somehow
the
element
type
is
somehow
implicit
in
this
right
right
fortune,
which
would
be
unfortunate.
C
A
Yeah,
I
think
the
proposal
that,
when
we
had
discussed
this
three
years
ago,
I
think
the
proposal
the
conclusion
from
that
was
to
go
away
from
some
of
these
typeless
opcodes
and
actually
introduce
not
just
the
128
512
and
256
bit
versions,
but
also
have
byte
short
int.
Long
double
and
float
versions
of
of
of
them
so
make
the
element
type
explicit.
A
A
So
when
we
discussed
this
a
few
years
ago,
it
was
we
had
the
same
kind.
This
was
I
mean
this
is
the
same
kind
of
discussion
that
we
had.
It
was
the
sort
of
the
shock
over
the
number
of
op
codes
that
this
may
introduce,
but
but
we
need
to
think
about
ways
of
potentially
reducing
reducing
that
number.
So.
C
C
B
C
A
I
I
think
it
would
be
an
easy,
an
easy
thing
to
add
in
the
future
if
there,
if
there
actually
was
a
use
case
for
them,
because
obviously
it
would
be,
there
would
be
an
asymmetry
with
with
vectors
and
and
and
the
scalar
scalar
types.
I
guess
the
one
thing
about
that
would
be.
Do
we
have
different
versions
for
100
like
returning
128
bit
100
returning,
you
know
256.
A
That
kind
of
thing
I
don't
know
those
are
things
that
we
would
have
to
think
about
and
unfortunately
we're
thinking
of
a.
I
guess
we're
trying
to
keep
by
introducing
them
now
we're
providing
a
solution
to
something
that
we
don't
really
have
a
need
for
at
the
at
the
moment.
Yep
yep,
that's
fair.
I
guess
I
guess
I
could
go
back
and
try
to
find
out
when
they
were
introduced
and
why
they
were
introduced.
I
mean,
obviously
somebody
had
a
need
for
that.
C
A
A
A
I've
got
the
agenda
open
for
the
may
30th
meeting.
So
if
you
have
any
topics
you
want
to
bring
up,
please
please
add
them
there.
I
will
just
say
that
I
was
I
was
close
to
getting
the
the
the
annotations
on
the
for
the
omar
extensible
class
annotations.
I
was
close
to
getting
that
incorporating
some
of
the
discussion
points
that
we
had
in
the
in
the
last
call
that
we
had
on
that.