►
From YouTube: OMR Architecture Meeting 20200910
Description
Agenda:
* New IL opcodes sbyteswap and lbyteswap (#5517) [ @aviansie-ben ]
* Should byte-reversed load/store opcodes be moved to OMR? (#5149) [ @aviansie-ben ]
A
B
Okay,
so
starting
off,
I'm
just
gonna
give
a
little
bit
of
background.
So
currently,
omr
already
has
a
an
op
code
for
reversing
the
order
of
bytes
in
a
32-bit
integer.
So
we
already
have
an
I-byte
swap-op
code,
and
these
kinds
of
opcodes
are
very
useful
for
converting
between
big
endian
and
little
endian
representations
of
integers.
B
B
So
I
don't
think,
there's
terribly
much
implementation
work
here
and
these
op
codes
are
basically
analogous
to
our
existing
ibyte
swap
op
code,
but
for
16
and
64-bit
values.
So
I
don't
think
there's
terribly
much
going
on
here.
One
thing
andrew
did
bring
up
was
the
potential
of
also
doing
a
bite
swap.
B
B
B
B
So
the
reason
that
I
don't
I'm
not
proposing
doing
this
on
floating
point
values
is
because
I
don't
actually
know
of
any
architecture
that
lets
you
do
a
byte
reverse
directly
on
a
floating
point
value.
So
typically,
you
would
have
to
move
it
into
a
gpr.
Do
byte
swap
there
and
move
back
so
it
would
be
better
to
just
represent
it
as
an
integer
byte
swap
followed
by
a
bit
conversion.
C
B
D
Ben
just
following
up
on
the
floating
point
question:
if
you
were
going
to
use,
say
the
eye
byte
swap
or
the
l
byte
swap
to
do
the
floating
point
reversal,
I'm
a
little!
I'm
not
quite
sure
what
the
trees
would
have
to
look
like
for
that,
because
if
you
added
like
an
f
to
I
or
d
to
I
or
d
l
or
whatever,
to
convert
the
type
of
the
node,
you
would
be
implying
changes
in
how
the
bit
pattern
is
represented
in
memory
because
you're
changing
the
type.
B
C
B
C
B
C
A
E
Yeah,
I
can't
remember
this
coming
up
before,
and
at
least
as
long
as
we've
been
discussing
il
changes
really,
but
that
would
be
the
only.
I
guess
concern
if
there
was
some
if
we
had
gone
through
some
evaluation
of
and
like
the
usual
sort
of
process
for
deciding
whether
something
should
be
a
new
op
code
or
not,
and
came
to
that
conclusion
for
some
reason
that
we
somehow
haven't
been
able
to
replicate
in
this
meeting.
That
would
be
the
only
concern,
but
I
can't
think
of
one.
C
A
A
B
If
I
understand
we're
all
on
the
same
page
about
s,
byte
swap
and
l
byte
swap
does
anybody?
Has
anybody
come
up
with
a
use
case
for
a
byte
swap
or
does
anybody
have
any
reason
that
we
should
add
that
I'd
rather
not
add
it
until
we
have
a
use
case,
though
yeah
I
don't
see
any
reason
myself
right
now,
so.
E
E
D
Well,
if,
if
the,
if
the
precedent
is
that
for
f
and
d,
you
do
f
bits
to
I
and
d
bits
to
l,
then
it
would
follow
that
a
should
go
through
either
a
to
I
or
a
to
l
right,
and
there
can
be
a
comment
to
that
effect.
Put
in
the
il
file
where
we
document
these
that
we've
done
we're
doing
them
simply
based
on
the
width
right
s
I
and
l,
and
if
you
need,
if
you've
got
some
other
type,
that's
carrying
additional
semantic
information.
D
A
C
And
going
back
to
the
prior
point
that
andrew
was
making,
I
think
it
would
be
good
to
document
in
some
way
the
rationale
for
not
introducing
a
bite
swap
at
this
point,
because
we
started
this
meeting
with
there's
an
eye
byte
swap
in
our
opcode
list,
but
we
don't
have
these
other
ones.
Does
anybody
know
the
reasons
why
that
was
done
and
we
don't
want
to
have
that
conversation
again
so
documenting
the
discussion
now
would
be
good
when
you
add.
B
D
Well,
just
for
my
personal
opinion
would
be
to
put
a
comment
somewhere
in
the
in
the
code,
possibly
where
we're
declaring
the
properties
or
something
like
that,
just
to
say
that
we're
just
using
these
ones
for
the
widths
and
that
we
don't
need
the
a
and
floating
point
equivalents
because
of
right,
just
documented
somewhere
in
the
code
where
we
codify
the
op
codes,
so
that
we
don't
have
to
go.
Looking
for
a
separate
issue.
E
A
B
B
B
B
C
D
A
C
C
F
D
C
C
E
Yeah,
I
think
the
anomicity
was
the
area
that
I
was
trying
to
think
of
an
example
where
it
would
cause
a
problem
too,
but
I
think
I
can't
think
of
one
either
unless
somehow
you
would
use
a
purely
theoretical
notion.
You'd
use
some
type
of
atomic
load
for
the
reverse,
the
byte,
reverse
load
and
not
and
you'd
end
up
using
a
non-atomic
version
of
the
load.
E
In
the
other
case,
you
could
get
different
behavior,
but
I
don't
think
that's
terribly
likely
so
and
I
think
anything
else
you
can,
if
you
happen
to
do
different,
commenting
on
the
load
versus
the
white
reverse
case.
That
would
be
another
thing,
but
we
can
handle
that
in
the
pattern
matching
of
the
evaluator
and
based
on
the
use
case
that
philip
just
described
it
doesn't
sound
like
you
have
that
very
frequently
anyway.