►
From YouTube: OMR Architecture Meeting 20210610
Description
Agenda:
* Consistent address formatting in compiler logs (#5991) [ @0xdaryl ]
* Update on short and medium-term compiler technical debt reduction [ @fjeremic ]
A
A
So
I
thought
that
we
should
probably
go
through
and
and
come
up
with
a
consistent
address
format.
So
this
is
not
the
first
time
that
this
has
happened
with
the
compiler
code.
I
think
almost
20
years
ago
now,
maybe
2002
something
like
that.
Maybe
2003
there
was
an
effort
to
provide
a
consistent
address
format
specifier
for
use
throughout
the
compiler.
A
The
challenge
there
was
that
we
were
getting
the
same
problem
across
different,
build
compilers
and-
and
we
wanted
to
have
some
means
of
standardizing
that
so
at
that
time
got
a
bit
more
background
here.
At
that
time
there
was
a
a
macro
introduced
into
the
code
called
pointer,
printf
format
that
still
exists
to
this
day.
There's
quite
a
few
uses
of
it
in
the
code,
mainly
in
the
in
the
ras
folder,
and
the
the
that
particular
macro
was
intended
to
be
used
anytime.
A
A
There
was
some
adoption
of
that
early
on
and
a
number
of
places
were
changed
in
the
jet
to
use
that,
if
not
all
of
the
places,
I
don't
remember
if
that
was
the
case,
but
a
lot
of
the
places
were
changed,
but
in
that
time
I
don't
think
it's
really
been
other
than
that
initial
effort.
I
don't
think
it
was
really
widely
adopted,
and
you
know
there's
there's
perhaps
some
reasons
for
that.
It
is
a
it.
You
know,
awareness
is
one
thing.
A
People
need
to
know
that
it
exists
to
use
it.
You
know,
convenience
is,
is
another
people
when
they're
writing
out
addresses
for
a
message
that
they're
producing
that?
Maybe
that
they're
only
going
to
think
that
they're
only
going
to
consume
it,
they
print
it
out
in
the
format
that
they
want
and
so
on.
A
So,
but
I
think
that,
in
order
to
go
through
this
exercise
of
producing
a
consistent
address
format,
I
thought
that
it
would
be
maybe
useful
to
reintroduce
or
or
revamp
that
that
macro
that
we
have
so
for
one
thing
I
wanted
to
make
it
a
bit
shorter.
So
what
I
ended
up
doing
was
just
in
this,
and
I
didn't
go
too
far
with
this.
By
the
way
I
just
want
to
get.
I
did
a
little
bit
to
see
how
it
looked,
and
I
wanted
to
get
some
opinions
on
how
things
looked.
A
So
I
essentially
just
created
a
sample
pr
here.
It's
not
intended
to
be
committed
at
all.
It's
just
to
demonstrate
code
for
people
to
look
at
and
once
you
know,
there's
some
consensus.
Then
we
can
go
ahead
with
with
more
changes,
but
essentially
I
I
renamed
that
to
tr
format,
specifier
pointer,
it's
got
a
prefix
of
tr,
mainly
to
keep
it
in
the
tr
name
space,
but
I'm
not
particularly
wedded
to
that,
because
it
does
make
it
a
bit
longer.
A
So
I
could
drop
that,
but
yeah
it's
intended
to
be
used
in
places
where
we're
printing
an
address
into
the
log
and
those
addresses
actually
come
from
two
different
kinds
of
variables.
One
are
true
c,
plus
plus
pointers,
and
then
the
other
are
addresses
that
are
stored
in
some
integral
type,
such
as
a
uint
pointer.
A
There
may
actually
even
be
cases
actually.
I
know
there
are
cases
where
addresses
are
even
stored
in
32s
on
some
32-bit
paths
or
in
64
on
some
64-bit
path.
So
I
mean
obviously
fixing
those
up
might
be
might
be
worth
doing
as
well
from
you
know,
getting
them
to
use
pointer
types,
but
that's
not
the
purpose
of
this
of
this
of
this
particular
pr.
So
any
format
specifier
that
we
use
has
to
kind
of
handle
both
c
plus
pointers
and
and
integral
types.
A
But
the
one
challenge
with
using
that
as
your
format,
specifier,
is
that
you
have
to
provide
some
casts
of
the
data
that
you
want
to
print
in
order
to
eliminate
compiler
warnings
and
and
compile
warnings,
if
maybe
philip
will
mention
that
in
a
in
a
few
moments.
But
if
you're
not
already
aware,
warnings
are
now
enabled
sorry,
warnings
are
now
treated
as
errors
when
building
the
jit
component
or
the
compiler
component
on
on
x86
platforms.
So
whatever
is
done
here
has
to
be
done.
A
A
So,
in
order
to
do
those
casts
and
to
keep
the
to
keep
things
as
concise
as
possible,
I
introduced
two
sort
of
helper
macros
that
you
pass
in
the
value
that
you
want
to
print
and
it'll
do
the
appropriate
cast
for
you.
So
the
first
is
if
it's
a
pointer,
if
it's
a
c,
plus
plus
pointer
type,
you
have
to
cast
it's
a
pointer
to
a
format,
specifier
pointer
and
if
it's
an
integral
type
like
a
uint32
or
something
like
that,
you
need
to
use
int
to
format
specifier
pointer.
A
So
just
wanted
to
introduce
that
and
get
people
to
to
maybe
look
through
the
the
changes
that
have
been
made.
I
didn't
realize
that
was
45
files.
That
seems
large
wow,
but
just
because
this
is
nowhere
near
this
is
just
a
dent
in
the
in
the
number
of
places
that
would
have
to
get
changed,
but
just
want
to
get
your
feedback
on
how
those
look
and
and
what
you
think
of
the
overall
approach.
A
A
One
other
thing
that
I
wanted
to
mention
as
well
along
this
lines,
I
guess
going
back
to
the
original.
The
original
attempt
at
doing
this
by
when
the
pointer
printf
format
was
introduced,
was
how
to
ensure
that
going
forward.
We
maintain
you
know
we
continue
to
do
this
for
for
messages
that
get
printed
to
the
log,
and
I
don't
have
a
great
answer
on
that
other
than
you
know,
as
as
developers
and
committers.
We
need
to
be
diligent
on
on
spotting.
A
A
You
know
the
the
use
of,
for
example,
percent
p
and
as
a
format
specifier
in
strings
and
then
issuing
a
warning
there.
I'm
not
super
keen
on
that
idea
only
because
there
may
actually
be
legitimate
reasons
why
legitimate
places
where
you
do
want
to
have
a
percent
p
and
in
in
messages
that
aren't
going
to
the
log.
So
I
don't
want
to.
A
B
A
That's
that's
right.
There
were
ish
and
it
it's
so
I
guess
two
things
to
that.
So
one
is
not
all
of
our
pointers
are
not
all
not
all
the
addresses
that
we
want
to
print
are
pointers
like
they're,
coming
from
a
pointer
to
something
they're
actually
represented
as
an
integral
type,
which
would
need
a
cast
to
a
pointer.
I
think
I
guess.
B
A
So
that's
that's
one
thing
and
then
the
other
thing
is
even
with
percent
p.
I
think
we're
getting
different.
That
is
a
I
guess,
a
compiler
implementation
defined
like
there's
no
standardization
on
percent
p,
and
we
are
at
least
at
one
point.
We
were
seeing
different
outputs
based
on
the
compiler
that
was
being
used.
So
I
think
that
was
what
was
driving
the
use
of
pointer
print
def
way
back
when
so.
A
Yeah,
that's
yeah.
That
is
a
drawback
for
sure.
If
there's
ways
of
reducing
the
size
of
these
certainly
be.
You
know
willing
to
consider
that,
but
the
other
thing
about
like,
like
we
mentioned
before,
I
think
we're
gonna
you're
gonna-
have
to
introduce
a
cast
of
some
sort
for
for
the
things
that
just
aren't
pointers
at
this
point.
B
A
A
The
one
little
wrinkle
in
all
this
as
well
or
the
challenge
in
all
of
this
is
that
there
are.
There
are
a
lot
of
places
to
change.
It's
not
just
a
matter
of
finding
all
the
percent
p's,
it's
finding
all
the
you
know
the
other
ways
that
addresses
are
being
printed
like
you
said
before,
with
the
percent
x's
and
the
percent
lx's,
and
you
know
all
these,
you
know
there
are
places
that
are
using
pri
x,
pointer
already,
and
so
it's
it's
a
real.
A
Okay,
so
if
there's
no
other
discussion
on
this
particular
topic,
then
I'll
just
stop
there
for
that,
and
we
can
move
on
to
our
next
topic,
which
is
an
update
from
philip
on
some
of
the
work.
That's
you
may
have
seen
happening
of
late
to
reduce
the
some
of
the
technical
debt
problems
that
we've
had
in
the
back
ends
and
some
of
the
other
work
that's
going
to
be
coming
up
in
the
short
term
to
to
further
that
work.
C
C
C
I
think
issues
from
both
open,
g9
and
omar,
but
if
we
just
take
a
look
at
the
omro
ones,
there's
epics
for
different
cleanup
items
in
different
areas,
for
example,
cleaning
up
of
genome
project
specific
if
depths,
testing
improvements,
documentation,
conceptual
integrity,
improving
trill,
unifying
the
the
cogen
control
and
some
ras
improvements,
and
then
we
have
pipelines
for
where
some
of
the
issues
that
we've
opened
up
in
you
know
omar
and
where
they
land.
So
I
guess
part
of
this
is,
I
guess,
a
call
to
action.
C
C
This
one
happened
to
have
most
of
the
work
in
open
j9,
there's
only
a
handful
of
warnings
that
we
fixed
to
get
os
x
up
and
running
with
warnings
as
errors,
but
then
moved
on.
Last
week,
we
actually
merged
a
big
pr
to
enable
warnings
as
on
windows
and
linux,
so
that
gives
us
all
the
x86
platforms
and
in
particular,
three
different
compiler
tool
chains.
So
we
have
gcc
clang
and
visual
studio,
both
all
three
compiling
with
warnings
as
errors,
so
that'll
make
the
job
easier.
C
C
A
lot
of
the
code
across
the
platforms
for
registered
dependencies
are
quite
common.
There's
not
really
too
big
of
differences
between
them.
So
there's
quite
a
lot
of
code
deleted
on
a
bunch
of
platforms,
for
example
on
art
64.
We
only
have
you
know
two
two
functions
that
are
specific
to
ar64
in
our
registered
dependencies
now
and
we
eliminated
things
like
tr
underscore.
C
C
So
it's
the
the
il
followed
by
the
evaluator
keyword,
there's
still
quite
a
lot
of
work
to
be
done
here
and
that
we
can
inline
a
lot
of
the
code.
That's
currently
present
in
these
stub
evaluators
into
the
actual
evaluator
itself.
It
sounds
part
of
this
cleanup
type
work,
making
things
look
the
same
across
the
platforms,
making
it
easier
for
developers
to
work
on
multiple
backends.
At
the
same
time,
other
work
we
did
unifying
of
the
instructions
so
started.
C
A
couple
weeks
ago,
several
of
sudo
instructions
were
common
across
all
the
back-ends,
for
example,
register
associations,
the
invalid
opcode,
a
double
word
defined
directly
in
in
the
code
instruction
sequence,
things
like
fences,
labels
and
start
of
procedures
and
and
and
the
returns.
These
are
common
across
all
the
platforms,
so
we
went
in
and
changed
all
the
platform
specific
ones
to
the
common
ones.
C
One
caveat
here
is
that
they're
all
actually
lower
case,
which
might
be
a
change
for
some
platforms
which
used
to
uppercase
things
like
fences
and
labels,
and
things
like
that.
Of
course,
we
can
change
that
in
the
future.
If
we,
if
we
decide
to
do
that
as
well,
and
that
was
kind
of
where
we're
at
right
now
we're
still
working
towards
unifying
the
instruction
level
apis,
putting
in
particular
x86
and
arm
we're
using
their
own
custom
classes
for
representing
instructions.
C
And
I
went
ahead
and
wrote
just
a
couple
of
things
that
we'll
be
working
on
in
the
short
and
kind
of
medium
term.
We
plan
to
enable
warnings
as
errors
on
all
the
platforms,
I'll
probably
be
working
on
power
or
s390.
Next
and
once
we
have
all
the
platforms
which,
with
w
air,
we're
gonna
circle
back
and
turn
on
all
the
warnings
and
see
what
we
come
up
with
and
whether
it's
worth
our
while
to
fix,
literally
all
the
warnings
and
turn
on
w
all
as
well.
C
Of
course,
some
of
the
warnings
like
using
offset
of
on
non-pod
data
types
and
things
like
that.
We're
just
going
to
disable
for
now.
So
what
we
can
disable
warnings
in
our
cmake
definitions
as
well.
If
we
encounter
some
pesky
ones
that
are
probably
not
worth
fixing
or
that
introduce
too
much
noise
into
our
codebase.
C
Other
things
on
the
ci
front,
so
this
has
been
a
long-standing
issue
which
could
have
actually
fixed
late
last
year.
So
currently
we
have
on
our
actions.
We
actually
use
a
custom
action
for
our
polarquest
labor
labeler
and,
for
example,
the
first
time
contributor
and
it's
an
action
that
runs
on
a
chrome
job
periodically.
I
think
every
10
minutes
or
so
so
you
might
have
noticed
that
there's
a
delay
between
when
you
open
the
pr
and
the
bot
comes
in
and
automatically
labels
the
the
pr
with
the
appropriate
targeted
labels
or
the
components.
C
C
So
we
have
to
do
it
and
send
in
a
chrome
job
which
basically
scans
all
the
pr's
and
puts
the
labels
that
way,
so
they
actually
introduced
a
new
way
of
doing
this,
so
we
can
actually
have
a
proper
pull
request
action
now,
which
runs
on
the
pull
request
itself,
and
does
that
immediately?
So
there's
no
need
to
do
this
10
minute
delay
and
we
can
start
using
the
actual
official
labeler
action.
C
The
official
you
know
first
contributor
action
from
from
github
themselves,
so
we
plan
to
do
some
work
on
the
ci
here
as
well.
Next
things
is,
I
believe,
formatting.
So
this
is
the
big
one.
So
I've
been
doing
some
work
in
the
background
to
figure
out
what
has
changed
since
I
think
2018
the
last
time
we
made
a
push
to
format
our
code
base
in
an
automated
way
and
there's
some
interesting
new
developments
since
then
it
seems
get
up.
C
One
of
the
gripes
that
we
had
previously
was
that
people
had
to
install
a
claim
format
or
whatever
formatting
to
the
tool.
We
chose
locally
on
their
laptops
before
submitting
contributions.
Otherwise
the
tool,
the
the
automation,
run
on
a
pull
request,
and
it
would,
it
would
be
a
failed
job
basically,
which
tells
you
hey.
Here's
the
diff
that
you
need
to
apply
to
your
commits
to
fix
up
the
formatting.
C
You
can
keep
working,
however,
you
work
today
or
in
whatever
format,
you'd
like
submit
a
pull
request
and
the
tool
will
go
in
and
format
all
your
commits
for
you
and
force
push
to
your
branch.
Your
pr
branch
there's
also
alternatives,
for
example,
that
are
discussed
here
and
that
you
can
choose
not
to
do
force
pushes
you
can
get
the
tool
to
just
add
a
commit
which
fixes
up
the
formatting
and
then,
instead
of
creating
a
merge,
commit
we
can
just
simply
squash
dot.
C
Formatting
comment
away
when
the
when
the
committer
merges
the
pull
request.
So
there
seems
to
be
various
different
ways
that
we
can
handle
things
with
new
and
improved
actions
and
hopefully,
in
the
medium
term,
probably
towards
the
end
of
the
year.
I
hope
to
make
another
push
towards
automated
quote
formatting,
and
we
can
have
some
different
ways
of
doing
it
on
the
table
and
decided
as
a
community.
What
we
think
is
the
best
way
forward.
C
For
example,
architecture
level
sets
or
any
anything
else
that
you
might
want
to
generate
on
your
particular
platform.
So,
for
example,
for
il
today,
for
example,
for
the
icons
il
we
define
a
macro
called
upcode
macro
and
then
various
things
that
we
want
to
know
about
the
icons
il
and
then
to
generate
this
in
various
tables.
We
would
just
redefine
what
the
opcode
macro
is
so,
for
example,
for
just
the
the
ile
for
the
properties.
C
So
we
can
do
a
similar
thing
for
the
instructions
across
the
different
platforms
to
unify
that
and
have
a
consistent
way
of
defining
an
instruction
across
the
platforms.
No
need
to
go
off
to
you
know
three
or
four
different
files
and
make
sure
that
the
order
of
you
know
all
the
instructions
is
the
same
and
you
wrote
it
in
the
correct
place,
et
cetera.
C
And
finally,
I
think
the
last
thing
I
have
here
is
unification
of
memory.
References
quite
a
lot
of
that
code
is,
is
common
across
the
platform.
So
once
we
have
instructions
in
place,
we
can
start
to
unify
memory,
references
as
well
dynamically
allocating
registered
dependencies
and
being
a
little
bit
smarter
about
dependencies.
Overall,
I'm
sure
most
of
you
have
encountered
code
in
our
evaluators,
which
count
the
number
of
dependencies
that
you
might
need
and
then
create
a
registered
dependency
object
with
the
exact
count.
C
I
think
this
might
be
overkill.
We
can
just
do
this
dynamically
and
avoid
quite
a
lot
of
the
churn
of
counting
how
many
possible
dependencies
you
might
need.
We
can
just
dynamically
reallocate
underneath
the
hood
other
ideas,
the
workforce,
but
they're
all
is
having
high
level
apis,
for
example,
generate
add
instruction
in
the
common
cogen,
which
would
then
be
overwritten
in
the
various
backends
and
and
generate
for
example.
In
addition,
so
this
could
be
a
faster
way
to
prototype
evaluators
across
platforms,
which
are
usually
quite
simple.
C
They
have
typically
have
some
using
openg
m
as
an
example,
for
example,
in
I
don't
know
a
check
cast
and
value,
or
an
instance
of
it's
basically
just
checking
pointers,
doing
some
bit
twiddling
and
and
branching
to
different
places.
All
this
can
be
done
with
a
more
high
level
api
and
then
that'll.
Let
us
enable
us
to
bring
up
platforms
like
press
5
much
faster
than
we
would
do
today
and
then,
of
course,
platforms
can
override
these
things
and
implement
a
super
fast
sequence,
because
doing
something
like
this
might
not
be
quite
optimal.
C
Other
things
we
want
to
tackle
is
compiler
tests.
We
want
to
deprecate
them
in
favor
of
trip
tests
and
start
writing
a
bucket
of
tests
for
each
and
every
op
code
that
we
have
in
the
code
base,
because
I
don't
think
we
have
full
coverage
today
and
a
little
bit
more
love
to
the
the
build
system
to
fully
migrate
it
to
cmake.
C
I
know
we
use
make
files
today
for
some
of
the
projects
like
the
linter
and
I
think
pieces
of
the
compiler
test
and
legit
builder,
so
we
can
hopefully
migrate
fully
to
cmake
and
take
advantage
of
that.
So
a
lot
of
talking
for
me,
I
don't
know
if
anybody
has.
This
is
just
probably
a
piece
of
all
the
stuff
I
could
remember
or
write
down
it's
basically
a
very
fluid
to-do
list
that
always
keeps
changing
and
yeah
just
looking
forward.
C
A
Had
thanks
phillip
there's
a
lot
of
a
lot
of
good
stuff
there
of
the
last
couple
of
months
and
certainly
looking
forward
to
some
of
the
others.
These
other
changes
landing
in
the
coming
months
as
well
so
yeah
I'll,
also
echo
his
you
know
invitation
that
anybody
wishes
to
work
on
any
of
this
stuff,
there's,
certainly
a
healthy
backlog
of
tasks
that
can
be
taken
on
if
you
feel
like.
So
any
questions
for.
A
Fellow
okay,
if
not
those
were
the
only
two
topics
that
we
had
for
this
week.
I
have
created
the
the
issue
for
the
next
architecture
meeting
in
two
weeks.
So
if
there's
any
topics
that
you
want
to
create
suggest,
I
should
say:
please
add
them
to
that
issue
and
other
than
that.
That
should
be
it
for
today.
So
thanks
everyone
for
attending
and
we'll
talk
again
in
two
weeks.