►
From YouTube: OMR Compiler Architecture 20190425
Description
Agenda
* Introduce InstructionDelegate hierarchy (#3778) [ 0xdaryl ]
A
Okay,
welcome
everyone
to
this
week's
compiler
architecture
meeting.
So
for
this
week
we
have
one
topic
on
the
agenda:
maybe
not
a
particularly
large
one,
so
it's
actually
issue
or
its
issued
three
seven,
seven,
eight,
which
is
the
introduction
of
an
instruction
delegation
hierarchy
that
can
be
used
for
project
specialization
of
the
instruction
class,
so
I'm
just
going
to
go
in
through
the
proposal
happy
to
hear
any
thoughts
or
alternatives
to
the
to
the
design.
A
A
But
the
problem
is
that
in
some
cases
the
there
are
some
instances
where
some
of
the
instruction
kinds
themselves
may
require
project
specialization
and
there
isn't
really
a
convenient
way
of
doing
that
outside
of
outside
of
using
gift
depths
and
I'm,
not
saying
that
if
deaths
are
the
convenient
way
of
doing
it
either,
because
there
are
certainly
some
complications
and
some
ugliness
associated
with
that.
So,
having
said
that
is
a
valid
issue.
A
A
of
doing
it
is
by
introducing,
if
desk,
to
understand
which
part
which
functions
can
be
overridden
in
projects,
and
that
kind
of
thing
you
can
provide
alternate
implementations
for,
but
I
didn't
really
want
to
consider
that,
because
it
is
ugly,
especially
if
you
have
multiple
functions
that
might
want
to
get
overridden
that
way
and
also
because
we
already
have
a
mechanism
that
we've
architected,
namely
extensible
classes,
that
we
should
be
using
for
doing
this
kind
of
thing.
So.
A
We
didn't
actually
do
that
so
so
that
work
hasn't
been
done,
but
that
is
certainly
an
approach
that
that
we
can
do
here
is
to
actually
go
around
to
all
those
instruction
kinds
and
make
them
individually.
Extensible
classes,
following
in
the
design
here,
I
actually
have
a
little
example
here
of
what
that
code
would
would
look
like
don't
have
these
figures
numbered
it's
the
second
ASCII
diagram
there,
but
basically
you.
A
Basically,
you
could
provide
a
tomorrow
base
class
in
the
base
class
me
one
more
project.
You
could
revise
your
own
override
of
that
and
you
can
produce
a
concrete
class
from
that.
That's
a
perfectly
valid
thing
to
do.
The
main
drawback
of
this
approach,
though,
is
that
it
really
introduces
a
lot
of
files
to
your
to
your
to
the
to
the
code
base,
because
you
would
need
separate
files
for
each
class
that
you
that
you
make
accessible
this
way
and
because
the
instruction
hierarchy
may
have
multiple
like
many
many
instruction
kinds.
A
A
So
what
I've
decided
to
do
instead
was
to
actually
introduce
a
hierarchy
that
lives
in
parallel
to
the
existing
instruction
hierarchy
and
I've,
called
it.
The
instruction
delegate
hierarchy
and
the
whole
purpose
of
that
instruction.
Delegate
hierarchy
is
to
provide
basically
anchor
points
in
each
project.
A
For
so
it
says
you
have
either
the
the
purpose
of
this
hierarchy
is
to
provide
project
specific
static,
delegate
functions
to
instruction
kind
classes.
Static
is
key
because
we
don't
want
to
create
an
instance
of
this
hierarchy.
These
are
functions
that
can
be
called
from
anywhere
as
long
as
you
pass
it
an
instance
of
one
of
those
instruction
kinds
and
the
purpose
of
passing.
A
So
this
hierarchy
is
an
extensible
class
hierarchy.
It
follows
the
same
construction
rules.
There
are
some
subtle
differences,
though
one
is
the
fact
that
for
instructions
in
particular,
there
are
really
any
architectural
specific
classes,
because
you're
only
creating
this
for
a
particular
architecture.
So
you
wouldn't
in
a
normal,
normal
extensible
class
hierarchy,
you
kind
of
weave
in
and
out
between
architecture,
specialization
and
sort
of
the
common
code.
At
that
particular
project,
you
wouldn't
do
that.
You
would
basically
just
go
from
architectural
specialization
in
one
project.
A
You
extend
the
architecture
specialized
class
in
the
previous
project
in
Willmar,
and
only
static
functions
are
allowed
in
this
hierarchy.
The
idea
here
is
to
greatly
reduce
the
number
of
files
required.
You
basically
would
require
a
couple
of
files
in
each
project
for
all
the
instructions
that
you
want
to
handle
this
way.
A
A
And
then
just
the
last
little
diagram
here
just
shows
a
some
sample
very
simple
sample
code
of
what
this
would
actually
look
like.
So
if
you
actually
had
a
virtual
function
in
the
mem
instruction
class
that
wanted
to
do
that
say
this.
This
function,
Prem
that
wants
to
call
something
that's
project
specific.
A
It
would
actually
reach
into
the
instruction
delegate
hierarchy
and
pass
in
a
pointer
to
itself,
and
that
would
basically
find
the
right
version
that
you
want
to
call,
and
you
can
see
there
that
we've
got
an
ohm,
our
instruction
delegate
for
that
function,
but
we
also
have
a
project
specific
delegate
for
that
function.
So
in
this
case
it
would
end
up
calling
the
the
my
project
version
of
that
function.
A
A
One
potential
drawback
of
this
approach
as
well
is
that
this
class,
this
instruction
delegate
class,
has
a
danger
of
becoming
a
kitchen
sink
of
just
a
collection
of
static
functions
that
are
unrelated
to
each
other,
but
are
just
there
to
serve
certain
instructions
in
some
sense.
That's
pretty
much.
That's
pretty
much
why
this
is
this
hierarchy
exists,
is
to
provide
that
kind
of
functionality,
while
sacrificing
welcoming
in
and
reducing
the
number
of
files
required,
but
in
practice,
though
I
think
especially
for
the
instruction
hierarchy.
A
I,
don't
think
that
we're
going
to
see
that
explosion
in
the
number
of
project
specialized
functions,
there
will
be
some,
but
there
won't
be
a
an
overwhelming
number
that
would
make
this.
You
know
look
too
much
like
a
kitchen
sink,
so
so
the
code
itself
is
actually
fairly
simple
to
write.
I
didn't
actually
provide
a
pull
request
for
that
I
think
I
could
I
will
actually
that's.
This
is
something
we
want
to
do,
but
I
did
want
to
introduce
the
idea.
This
is
certainly
applicable
this.
A
This
kind
of
a
pattern
is
certainly
applicable
to
other
hierarchies
as
well.
It
doesn't
just
have
to
apply
to
the
instruction
hierarchy.
You
could
apply
to
things
where
it's
difficult
to
add
where
we
have
a
dynamically
polymorphic
hierarchy,
but
it's
difficult
to
add
project
specializations
there
I
have
the
symbol.
Hierarchy
is
one
that
comes
to
mind
as
well,
where
this
kind
of
thing
could
be
useful
there
too,
but
but
I,
don't
let's.
Let's
start
with
the
instruction
hurrican
see
how
that
how
that
goes.
A
House
is
better
than
a
virtual
function,
so
the
problem
with
the
virtual
flow,
the
problem
with
the
virtual
function,
is
that
you're
going
to
need
to
provide
you
even
need
some
place
to
provide
the
project
specialized
implementation
of
that
virtual
function.
So
at
the
moment
there
isn't
really
a
place
to
hang
that
so.
A
Because
in
some
cases
you
don't
actually
overriding
your
actually
replacing
that
version,
because
the
way
that
because
you
need
to
provide
your
own
version
of
that
funk
like
you're,
not
but,
for
example,
the
the
mem
x86
mem
instruction
you're,
not
actually
sub
classing
that
to
provide
your
virtual
function,
you're,
actually
replacing
a
function
and
alternate
implementation
of
that
virtual
function
with
your
own.
So
you
need
that.
You
need
some
kind
of
a
mechanism
for
saying
don't
use
that
implementation
use
this
implementation.
A
There
is
an
example
of
that
in
in
in
PowerPC,
actually,
where
they
override
one
of
the
call
instruction
classes
or
Mar
provides
its
own
version
with,
if
deficits
all
guarded
like
that,
and
then
they
have
a
version,
that's
in
in
open
j9,
where
they
provide
their
own
specialization.
For
that,
so
it
makes
a
lot
cleaner
and
that
kind
of
code
would
get
cleaned
up
by
this.
A
A
Is
the
end
goal
just
to
eliminate
the
genome
project?
Specifics
of
no,
the
the
goal
here
was
to
provide
project
specialized
behavior
within
certain
instruction
classes,
for
things
like
GC
maps
and
on
some
of
the
some
of
the
encoding
functions
was
to
provide
was
to
remove
some
of
the
project.
Specific
VA
I
mean
yes,
there
is
some
project
specific
stuff
in
there,
but
it's
not
really
guarded
with
it.
Def
project
specific.