►
From YouTube: OMR Architecture Meeting 20210204
Description
Agenda:
* RISC-V CI pipeline update [ @fjeremic ]
* Deprecate PrefetchInsertion optimization [ @fjeremic ]
* Switch to using Node::isSingleRefUnevaluated() in code generators (#5648)
* Avoid using TR::comp in Z InstOpCode utility functions (#5663)
* Standardize compiler getter/setter syntax (#4575)
* Size-optimized builds
A
B
B
I
documented
a
docker
file
which
is
pretty
much
a
guide
to
how
to
set
up
the
cross
compilation
with
what
yen
has
done.
So
he
pretty
much
did
all
the
work
there.
I
just
kind
of
consolidated
all
the
information
in
one
place
and
it
requires
us
to
build.
I
guess
a
risk.
Five
cross
compiled
tool
chain
root
file
system
on
deviant10,
and
you
can
use
that
in
qemu
to
actually
do
the
emulation
of
first
five
compiled
code.
So
that's
that's
all
been
done.
B
B
So
I
guess
for
reference
our
second
slowest
build
takes
about
20
or
20
25
minutes
or
so
so
it
kind
of
doubles
our
our
time
to
get
testing
done,
but
I
think
it
might
be
a
worthwhile
trade
because
doesn't
seem
like
we
merge
too
many
pr's
per
day
anyway.
So
I
think
it's
fine
to
get
the
trade-off
is
fine
to
get
diverse
five
tested,
that's
pretty
much
where
we're
at.
I
guess
the
goal
has
been
achieved,
we're
going
to
stop
progressing
verse,
5
moving
forward,
because
the
test
will
fail.
A
B
B
A
B
A
A
D
A
B
Okay,
so
I
tried
to
dig
this
one
back
to-
I
guess
2009,
when
it
was
first
introduced
internally
in
our
history,
and
I
can't
find
where
exactly
we
disable
it.
But
I
guess
to
summarize
this
optimization
what
it
does
is:
it
introduces
additional
loads
from
arrays
and
it
attempts
to
prefetch
their
their
values.
B
So
it
is
currently
disabled
by
default
for
forward
arrays
and
it
is
disabled
by
default
under
concurrent
scavenge.
This
is
a
recent
bug
that
we
found,
and
it
is
only
enabled
for
backwards
array,
traversals,
the
actual
algorithm
to
analyze
all
the
trees
and
figure
out.
The
right
insertion
points
is
an
n
squared
algorithm.
B
It's
quite
problematic
for
the
gc,
because
we
used
to
have
a
tail
heap
padding
so
a
couple
of
extra
words
at
the
end
of
the
heap
which
were
allocated
by
the
gc
to
make
this
optimization
work.
But
since
they've
gotten
rid
of
that,
you
can't
no
longer
prefetch
anything
towards
the
edge
of
the
heap,
which
means
you
could
get
a
sig
bus
failure,
for
example,
by
inserting
prefetches
in
the
forward
direction,
which
is
probably
why
it
was
disabled
and
in
the
backwards
direction.
We
now
have
modified,
for
example,
for
openg9.
B
A
I
only
have
a
fuzzy
or
fuzzy
interaction
with
prefetch
insurgent
over
the
years.
I
have
a
suspicion.
It
was
introduced
for
power
and
to
catch
some
opportunity
that
it
was
looking
for.
I
I
don't
remember
the
history
behind
it
at
all,
not
that
I've
gone
looking
for
it
either,
but
is
there
anybody?
That's
got
a
power
gita.
Perhaps
do
you
recall
if
this
is
a
a
historical
optimization
that
is
still
needed
on
power.
E
A
A
We
can
change
the
issue
itself,
so
I've
picked
three
from
from
the
history
if
you're
really
sharp,
you
would
have
saw
that.
I
had
four
initially
that
fourth
one.
I
wanted
to
do
a
little
bit
of
study
on
that
myself,
just
to
understand
what
that
is
really
all
about
and
whether
it
even
applies
anymore.
It
had
to
do
with
the
vp
handlers,
but
but
we
can
always
revisit
that
at
another
time,
so
so
the
first
one
here
is
it's
issue
5648.
A
I
think
ben
actually
opened
this
one
last
last
fall,
but
there
are
two
apis
that
exist
on
the
node
class
in
the
compiler
that
are
there
apparently
to
provide
more
readability
to
the
code.
So
there's
one
function
called
is
single
ref,
which
all
it
does
is
check,
whether
or
not
the
node's
reference
count
is
one,
and
then
there
is
a
second
api
is
single
ref
unevaluated,
which
checks
if
the
reference
count
on
a
node
is
one
and
the
register.
A
A
register
has
not
been
set
on
that
node
and
when
a
register
is
not
set
on
a
node,
that
is
usually
an
indication
that
that
node
has
never
been
evaluated
by
the
code
generator.
So
we
haven't
actually
produced
any
instructions
for
that
node
before
so
we
have
pretty
much
come
upon
it
for
the
first
time.
I
guess
you
can
think
of
it
that
way.
A
A
A
A
A
You
may
not
be
getting
the
answer
that
you're.
It
may
not
be
answering
the
question
that
you
are
actually
asking
right,
because
there
are
situations
where
the
code
generator
will
decrement
the
reference
count
on
a
node
without
updating
the
register.
So,
for
example,
if
it's
evaluating
a
constant
and
that
constant
fits
into
the
instruction
itself-
and
it
doesn't
need
a
register,
then
then
it'll
evaluate
decrement,
the
reference
count
and
then
the
the
register
field
will
still
stay
empty.
So
it's
not
like
the
first.
A
If,
if
you're
using
this
api
to
discover
the
first
time,
you've
come
across
the
first
and
only
time
you
see
a
node,
so
I
have
a
single
ref.
The
reference
count
is
one
and
it's
unevaluated,
if
you're
using
that
logic,
to
conclude
that
this
is
the
one
and
only
reference
to
this
node
and
I've
never
seen
it
before.
A
F
F
A
A
A
A
A
What
do
you
really
want
to
know
when
you're
asking
is
single
ref
unevaluated?
Are
you
asking?
Is
this
the
one
and
only
reference
to
this
node
and
if
so,
perhaps
that's
what
the
name
of
the
api
should
be,
and
I
guess,
depending
on,
if
you're
in
the
code
generator
or
not,
you
could
answer
that
question
different
ways,
depending
on
what
you
have
knowledge
of
as
long
as
you're
able
to
answer
that
question
exactly
the
same
way.
B
D
G
D
It's
possible
there's
some
other
question
that
could
be
asked.
That
would
be
the
right
question
and
could
be
unambiguously
answered
that,
but
I
think
is
single
ref
unevaluated
feels
to
me
like
a
kind
of
it's
almost
like
an
identity
based
kind
of
query
right.
It's
a
the
question.
You're
asking
asking
is
a
proxy
for
what
you're
actually
trying
to
figure
out.
So
we
should
really
just
ask
the
right
question
if
we
want
to
do
that.
G
C
D
That's
true
yeah!
So
if,
if
we
were
to
keep
this
because
we
find
it
useful
to
have
those
two
things
be
asked
at
the
same
time,
I'd
prefer
that
we
come
up
with
a
better
name
for
the
query
that
we're
asking
so
that
it
actually
is
the
question
that
we're
asking
in
all
of
those
cases
and
if
we
need
to
implement
two
queries,
two
things
and
answer
it
the
same
way.
Then
either
we
haven't
come
up
with
the
right
name
for
it
or
it's
you
know.
A
What
I'm
going
to
propose
is
just
dropping
a
comment
in
that
issue,
explaining
our
our
discussion
here
and
closing
the
issue
off.
Actually,
maybe
we
could
well
either
we
create
a
new
issue
to
to
remove
the
or
to
replace
the
the
uses
in
in
the
z
code
gen,
or
we
just
repurpose
that
that
issue
to
do
that
work.
F
A
A
So
this
is
to
avoid
using
the
tr
comp
thread:
local
storage,
query
in
the
z
in
stop
code
utility
functions.
So
there
are
a
number
of
utility
functions
for
the
z-op
codes.
The
z-instruction
op
codes
that
need
a.
They
need
to
do
a
query
on
the
compilation
object,
but
rather
than
passing
in
the
compilation
object
each
one
of
them
does
a
query
through
tier
comp,
which
is
a
thread
local
storage,
lookup
tls
lookup
tends
to
be.
A
I
think
it
is
considerably
more
expensive
than
simply
passing
in
the
compilation
object
to
each
of
these
utility
functions
and
then
using
that
instead,
so
this
work
proposes
getting
rid
of
tr
comp
usage
in
all
those
utility
functions
and
simply
passing
in
the
compilation
object.
So
you
have
to
go
around
all
the
code
and
change
the
change.
A
A
A
Okay,
the
next
one
is
standardizing
the
compiler
getter
center
syntax,
so
four,
five,
seven
five.
So
this
actually
came
out
of
a
discussion
in
some
issue.
I
can't
or
a
pr
I
can't
remember
when
it
was
a
while
ago,
like
a
long
while
ago,
when
the
when
the
compiler
code
was
first
written,
you
know
20
years
ago
and
for
a
good
part
of
its
life,
the
the
convention
being
used
for
getters
and
setters
was
to
use,
get
you
know,
followed
by
the
field
name
and
set
followed
by
the
field
name.
A
However,
over
time
another
format
has
has
started
to
creep
into
the
code
and
is
actually
prevalent
in
a
lot
of
places
in
the
code,
which
is,
I
think,
an
attempt
to
make
the
code
more
readable,
but
for
the
getters
it's
to
is
to
omit
the
get
and
then
just
use
the
field.
Name
with
you
know,
use
the
field
name
with
a
like
as
a
function,
so
it's
like
it
would
be
lowercase
or
something
like
that,
but
you're
just
using
a
function
name
rather
than
get
field.
A
A
I
mean
it
may
seem
a
bit
like
a
bit
like
a
waste
of
time
to
come
up
with
this,
but
I
think
just
from
a
consistency,
point
of
view
and
and
making
the
code
base
homogeneous,
it
could
be
useful
to
do
and
it's
easy
for
us
to
check
like
in
code
reviews
and
things
like
that,
that
that
someone
is
doing
the
right
thing.
So
I
guess
the
question
is
which
format
is?
C
D
B
A
G
A
B
D
So
I
use
that
to
that
idiom
in
in
jit
builder,
for
for
some
kinds
of
initialization,
just
because
it
makes
for
a
nice
kind
of
take
the
object.
Then
you
know
arrows
set
this
arrow
set.
This
arrow
set
this
arrow
set
this
and
it
just
kind
of
lays
it
out
nicely
for
initializing
the
object
or
updating
the
object.
If
you
need
to
do
something
like
that,
so.
B
B
D
A
D
A
G
A
A
So
one
example
that
I
will
give
this
is
not
the
only
example,
but
it's
just
one.
One
thing
that
we
have
found
when
we
did
poke
into
this
a
bit
was
the
the
gpu
support
in
the
in
the
in
the
in
the
jet
and
in
the
compiler,
and
some
of
the
things
that
that
get
pulled
in
with
that
now.
This
isn't
so
much
of
an
omr
consideration.
A
It's
maybe
more
of
a
concern
in
in
downstream
projects
like
open
j9,
which
which
will
pull
in
a
lot
more
from
that,
but
the
the
idea
here
is:
you
know
we
for
something
like
that.
We
could
have
prevented
that
from
happening
if
we
were
able
to
do
a
build
that
excluded
certain
things
from
from
a
size,
optimized
build.
So
if
you're
really
concerned
about
producing
the
smallest
possible
size,
here's
a
build
option
that
you
can
use
that
you
can
use
to
guard
code
that
you
would.
You
would
potentially
consider
to
be
optional.
A
Perhaps
all
of
these
sorts
of
features
should
actually
have
their
own
kind
of
option
where
you
can
or
build
option
where
you
could
enable
it
or
disable
it.
So
you
could
build
it
in
or
build
it
out.
If,
if
you
want
and
that
way
you
could
control,
you
have
more
refinement
over
how
you
are
controlling
what
gets
included
in
your
build
or
or
what
what
feature
gets
included
in
your
build
and
what
doesn't
now
like.
A
We
already
do
that
at
sort
of
the
component
level,
like
gc
or
port
library
or
thread
library,
but
we
don't
do
it.
Let's
say:
if
you
look
within
the
compiler
you
don't
you
don't
see,
features
that
are
you
that
that
you
can
disable
like?
I
don't
want
to
build
a
certain
class
of
like
I
don't
want
loop
optimizations,
for
example,
or
I
don't
want
you
to
do
any
data
flow
or
anything
like
that
or
I
don't
want
cuda
support
or
gpu
support
or
cmd
support,
or
something
like
that.
A
D
So
the
original
is
like
we
used
to
have
the
small
jit
right,
so
the
way
that
that
was
done
was
there
was
a
query
called
is
small
that
was
propagated
with
just
if
statements
throughout
the
whole
code
base
in
various
places,
and
that
is
small-
was
an
inlined
pound
if
dime
pound,
if
deft
return
value
so
the
pound.
If
def
didn't
propagate
everywhere,
although
it
was
necessary
in
places.
A
A
A
First
of
all,
whether
or
not
it's
a
it's
a
good
idea,
if
it's
something
that
it
needs
and
also
what
is
the
best
strategy
going
forward,
I
think
there
already
is
actually
an
issue
that
somebody
created
years
ago
in
omr
to
add
capability
kind
of
flags
to
the
to
the
build
I'd
have
to
go
look
for
that.
I
just
remembered
that
now,
when
I'm,
while
I
was
speaking
here
to
see,
if
that's
still
around,
if
something
there's
something
there
can
get
resurrected.
C
A
little
bit
worried
about
taking
sort
of
pieces
out
of
optimizer,
because
behavior
can
become
completely
sort
of
unexpected.
You
never
know.
Actually,
if
you
move
remove
something,
something
else
will
not
happen
right.
It's
not
as
sort
of
independent
all
these
optimizations,
they
pretty
much
depend
on
each
other.
D
A
I
mean
the
biggest
thing
that
we
found
so
far
was
was
all
the
gpu
work
and
the
cindy
support
cindy
instruction
support.
You
know,
potentially,
if
you
wanted
a
much
like
a
really
stripped
down
kind
of
optimizer,
you're,
only
let's
say
interested
in
up
level
cold
or
something
like
that.
Potentially
you
could
build
out
all
the
optimizations
that
you
don't
want
to
enable.
A
G
G
C
I
A
Well,
if
the
micro
jet
can
be
well
there
were
I
mean
there.
There
are
a
couple
of
you
know
there.
There
are
those
that
have
that
have
taken
the
omr
compiler
and
tried
to
integrate
it
into
a
completely
different
front
end
than
what
we've
traditionally
been
used
in
and
in
those
contexts
you
know
there
they
they
discovered
that
it's
just
simply
too
large
for
their
for
their
needs.
But
I'm
not
sure,
if
I
mean
is
the
micro
jet
being
designed
to
be
used
in
for
more
than
just
java.
G
D
Well,
to
be
fair,
there
are
some
facilities
available
already
in
the
compiler
that
help
strip
things
down
right.
So,
if
you
don't
or
if
you're,
if
you're
willing
to
go
to
this
to
the
code,
extreme
of
creating
your
own
extension
of
the
omar
compiler,
you
can
configure
the
optimizer
to
not
include
optimizations
that
you're
not
interested
in
so
jitbuilder.
Does
that.
G
G
D
Right,
well
I
mean
that
was
that
was
work
at
the
level
of
the
optimizations.
So
if
the
optimizations
pulled
in
things,
then
it
would
just
kind
of
get
pulled
in
there
wasn't
much.
You
could
do
about
that.
But
if
you,
if
you
were
only
willing,
if
you
only
wanted
to
initialize
certain
optimizations,
you
wouldn't
have
to
pull
in
everything.
So
I
know
jitbuilder
saved
about
a
megabyte
of
of
size
in
the
in
the
jit
builder
library.