►
From YouTube: OMR Compiler Architecture 20190328
Description
Agenda
* Progress on Options re-design (#3675) [ @nbhuiyan ]
A
A
Okay,
welcome
everyone
to
this
week's
compiler
architecture
meeting.
So
we
have
one
topic
today:
Nazim
will
be
giving
an
update
on
some
of
the
work
that
he's
been
doing
to
prototype
a
new
scheme
for
processing
compiler
options.
If
you
recall,
we've
discussed
this
topic
a
few
months
back
and
really
just
to
sort
of
introduce
the
frame.
A
Why
we
want
to
do
this
and
the
problems
that
we
were
facing
in
and
what
a
new
architecture
might
look
like,
and
over
the
on
and
off
for
the
last
few
months,
Nazim
has
been
able
to
spend
some
time
working
on
studying
the
problem,
a
little
bit
more
and
coming
up
with
some
some
different
solutions.
So
what
he'll
be
talking
about
today
is
sort
of
the
progress
of
that
and
one
of
the
solutions
that
that
looks
fairly
promising.
That
I
think
we
might
consider
adopting
in
Omar
and
other
downstream
projects.
B
It's
a
currently,
as
instance,
there
is
just
a
giant
confusing
mess
that
someone
will
take
a
long
time
to
figure
it
out.
Based
on
my
experience,
yeah,
it
doesn't
mean
it
does
it,
and
another
thing
is
that
using
the
class
is
a
little
bit
more
complicated
than
it
could
be,
and
now
that
Omar
is
not
the
source
project,
someone
who's,
you
know
who's
a
new
developer
to
Omar
and
if
they
want
to
add
any
of
their
own
options,
that's
not
very
straightforward.
B
For
example,
adding
a
boolean
option
right
now
would
mean
requiring
a
change
in
a
warm
our
options,
HBP,
as
well
as
a
table
entry
that
is
in
an
array
that
is
alphabetically
sorted
by
the
option
later
in
one
more
options
are
CVP
and
then
any
way
else.
Yeah.
That's
not
a
very
neat
way
to
add
one,
and
another
issue
we
have
is
that
the
current
implementation
limits
us
in
the
sense
that
a
lot
of
the
downstream
project
options
cannot
exist
in
there
in
the
projects
themselves
and
they
have
to
exist
within
a
llamar.
B
B
There
are
member,
so
basically,
these
members
are
not
hard-coded.
They
are
actually
generated
at
build
time
and
those
generated
files
are
included
within
within
places
where
we
know
you
need
those
data
and
we
will
get
back
into
the
when
you
get
into
the
details
about
that
in
upcoming
slides.
So
we
have
one
input.
B
Json
file
for
OMR
and
downstream
projects
can
have
their
own
JSON
files
containing
their
own
options
and
then
another
design
change
that
has
happened
was
that
we
no
longer
use
the
unordered
array
anymore
for
matching
option
string,
but
we
instead
use
a
is
a
hash
table
that
is
laid
out
during
real-time
and
yeah.
We'll
talk
more
details
about
that
later,
but
first,
let's
look
at
some
of
the
justifications
behind
using
boolean
options.
Members,
instead
of
continuing
to
use
the
options
array
field.
B
So
what
happens
with
this
implementation
is
that
we
cannot
separate
OMR
options
from
downstream
options,
so
downstream
projects
will
have
to
have
their
options
here
as
well,
and
this
is
a
big
problem
because
of
the
fact
that
there
is
a
limit
to
the
number
of
options
that
we
have
because
they're
on
the
in
answer.
If,
like
these
enum
members,
are
defined
to
fixed
values,
there
is
a
range
and
the
maximum
number
we
can
have.
It
is
about
eight
hundred
thirty
members
so
and
another
disadvantage
of
using.
B
B
Specific
options
do
not
have
to
worry
about
each
other
and
then
another
advantage
is
that
coining
of
these
options,
which
I
mentioned
if
something
that
happens
quite
often,
is
actually
two
to
three
times
faster
than
using
bitwise
operations
to
extract
the
boolean
information
and
I've
done
that
by
writing
a
small
test
making
one
billion
billion
queries
of
different
options
in
the
two
different
implementations,
and
the
fact
is
that
using
boolean
fields
does
increase
the
size
of
our
class.
The
options
object,
but
the
thing
is
given
the
number
of
waiting
we
do.
C
Just
a
question
on
that
particular
point:
most
of
that
bullying,
most
of
the
math
that
most
of
the
instructions
that
would
be
necessary
to
do
the
extraction
or
contained
in
a
relatively
small
number
of
methods
right.
The
the
current
version,
the
bullying,
the
the
bitwise
operations,
are
not
spread
through
the
compiler
they're
centralizing
accessor
functions,
correct!
That's
right!
C
C
D
So,
okay,
so
me,
the
previous
thing
was
800
options.
It
was
limited
to
right,
so
that
kind
of
put
the
cap
on
how
much
exact
space
you're
talking
about
my
question
was
going
to
be
different.
I
was
just
curious.
How
long
it
took
a
billion
queries
to
like
you
made
what
time
two
to
three
times
doctor,
so
it
went
from
I.
B
D
B
B
Given
that
we
are
only
going
to
have
just
like
a
few
copies
of
a
few
instances
of
compiler
options
last,
we
don't
really
have
to
worry
about
the
memory
footprint,
given
the
fact
that
can
perform
queries
faster.
If
it
was
that
we
were
having
thousands
of
instances
of
the
options
class,
then
I
guess
you
it
could
be
a
valid
concern,
but
generally
we
don't
really
do
that
many.
B
A
B
Okay,
so
form
our
options
of
JSON
is
a
place
to
contain
it's
just
an
array
of
JSON
objects
containing
like
the
options,
data
that
needs
to
get
processed
before
it
can
actually
be
used
in
the
compiler.
So
the
omr
is
going
to
have
its
own
options.
You
know
more
often
so
JSON
and
downstream
browsers
can
have
their
own
version
and
the
script
that
handles
that
will
combine
the
information
from
both
for
building
out
those
tables
and
members
and
so
on.
E
B
So
here's
an
example
of
how
an
entry
in
the
options
are
JSON
file
is
going
to
look
like,
so
it's
going
to
have
if
you
feel
that
are
similar
to
the
option
table
that
currently
exists
in
all
of
our
options.
So
the
name
field
is
used
as
an
identifier
for
this
specific
option,
and
this
is
one
thing
that
we'll
have
to
show
that
is
unique.
B
If
it's
not
you,
if
we
do
have
a
duplicate
name,
the
script
is
designed
to
warn
the
user
about
the
fact
that
you
need
to
find
it
differently
and
then
category
like
currently
I'm
keeping
the
categories
that
like
how
they
are
right
now,
but
I
think
going
forward.
We
could
come
up
with
better
category
names
than
just
M.
B
So
description
field
is
used
for
get
for
outputting
information
like
it's
just
a
help,
text
information
and
then
the
next
part
is
often
member.
So
this
is
the
name
of
the
member
in
the
options
list
that
that
will
be
affected
by
this
option
being
on
the
command
line,
and
one
thing
might
notice
is
that
I
still
have
TR
underscore
prefixed
with
these
things,
even
though
it
doesn't
need
to
be.
But
there
is
an
explanation
for
that.
B
We'll
get
that
day
later
and
then
we
can
specify
the
data
type
of
that
member
and
then
the
default
value
and
then
the
processing
function.
If
we
find
this
specific
option
in
the
command
line,
then
that's
the
processing
function
that
will
handle
that
will
be
called
to
change
the
member
in
the
option,
number
field
and
then
suffer
table
currently
all
the
one.
No
because
I
haven't
added
the
options
of
fit
handling
yet.
C
B
Yes,
I
could
do
that
too,
but
for
so
oh
because
the
reason
I
did,
that
is
because,
in
my
Python
script,
I
am
simply
doing
string,
comparisons
and
and
right
now
what
I
would
do.
What
I
do
is
directly
write
the
default
value
into
the
output
file
based
on
like
okay,
so
I'll
have
to
go
over
the
options,
generator
script
to
explain
why
this
works,
but
I
could
set
it
to
false.
B
B
F
B
B
So
the
next
part
of
this
framework
is
the
options
gen.
So
it
is
a
Python
script
that
it
runs
at
Build
time
and
it
handles
the
JSON
files
we
just
walk
about
and
it
generates
the
multiple
dot
in
files
that
are
included
in
compiler
options
and
composite
office
manager
classes
so
that
they
include
options
during
that
contains
all
the
all
the
feels
better
going
to
be
part
of
compiler
options,
class
and
then
option
initializer
list,
dot,
Inc
that
and
that
contains
the
like.
The
member
initializer
list
with
the
default
values.
B
B
B
They
are
not
ordered,
but
they
are
putting
the
table
according
to
their
hash
values.
So
every
time
we
get
we
get
into
the
table,
we
get
a
bucket,
and
sometimes
it
could
be
more
than
one
entry,
because
sometime
because
there
could
be
collisions
happening,
would
it
try
to
reduce
the
collisions
and
make
the
hash
table
minimal?
B
But
given
the
set
of
stream
names
that
we
have
I
have
tried
to
make
it
as
perfect
as
possible,
trying
to
mimic
a
G
first,
perfect
hash
function
generating
mechanism,
but
the
problem
with
that
was,
it
was
taking
an
extremely
long
time
so
to
generate
a
perfect
hash
table
and
also
the
table
being
generated
was
extremely
sparsely
populated.
So
that
was
not
an
ideal
State
and
we
weren't
really
saving
much.
B
We
were
in
really
gaining
much
by
going
through
all
that
pain,
which
is
why
I
decided
to
allow
some
collisions
and
another
and
put
in
a
collision
handling
mechanism
in
place
where
every
time
we
get
a
bucket,
we
do
is
string
comparison
with
the
option,
string
and
option
the
table
entries
name.
So
in
that
way
we
ensure
that
we
get
the
correct
entry.
This.
B
Yeah,
so
what
I'm
using
is
a
modified
version
of
Borenstein
string,
hashing
function
and
I'm,
using
a
multiplier
of
seven
and
also
I
limit
the
hash
table
size
to
twice
the
size
of
the
number
of
the
twice
the
number
of
entries
that
we
have
so
that
we
have
some
sort
of
spread
and
also
not
a
very
large
tip.
Otherwise,
it
does
get
quite
large
because
I
using
a
CD
map
and
orders
that
I
did,
but
the
problem
with
that
that
was
actually
my
initial
design
before
they
generated
then
came
along
go
back.
B
B
Constants
question:
you
know:
no,
we
don't
that
would
be
making
the
sensor,
but
we
don't.
Unfortunately,
it's
like
this
all,
not
the
only
simple
subversion,
specific
issue:
I
faced
it
along
the
way,
but
yeah.
It
would
be
great
if
you
could
do
that,
but
unfortunately,
because
of
that,
like
won't,
the
main
motivations
behind
using
a
generator
approach
is
that
all
of
these,
like
known
strings,
that
we
have,
can
be
used
ahead
of
time.
We're
not
changing
that
at
run
time.
B
So
why
not
just
build
it
up
and
then
use
it,
and
in
this
way
is
much
cheaper.
Doesn't
impact
startup
shouldn't
because
I
don't
have
the
measurements
like
start
of
measurements,
because
it
has
to
be
because
I
would
like
to
have
it
integrated
within
j9
before
doing
any
kind
of
measurements
like
that
so
yeah.
But
theoretically,
it
should
be
better.
This
way.
B
B
So
next
part
options
below
nothing,
interesting,
except
it's
using
the
initialization
of
options
and
handle
handles
stuff
like
parsing,
command-line
and
environment
options,
etc,
and
then
compiler
options
we've
spoken
quite
a
bit
about
it
and
it's
basically
nothing,
but
just
it
just
contains
the
generated
file
it.
That
is,
that
is
generated
from
using
our
JSON
object.
B
Next
is
compiler
options
manager,
so
it
kind
of
holds
the
whole
thing
together
and
it's
an
extensible
class,
because
sub-projects
should
be
able
to
determine
how
they
want
to
initialize
options
and
whether
there
is
any
and
you
like
any
kind
of
new
information
that
they
want
to
add
to
option
wearing
in
general.
So,
and
it
is
also
the
class
data
query
for
getting
your
options,
object
specific
to
your
compilation
or
just
a
global
command-line
option.
B
A
I
was
going
to
ask
how
a
downstream
project
would
actually
consume
this,
so
do
they
does
that
project
have
to
run
its
own
script
and
like
is
there
only
one
version
of
all
those
dank
files
that's
produce
tours
or
I?
Can
all
our
version
of
those
dotting
fails?
That's
a
a
j9
version
of
those
dotting
files,
and
then
you
somehow
recommend
to
gather
in
that
endless
differ
files,
or
does
it
just
produce
one
version
of
that
dotting
file
somewhere
that
gets
included
so.
B
B
A
B
So
currently
in
the
current
bill
system,
where
these
files
files
get
the
put
is
under
the
bill,
directs
the
current
bill
directory
and
then
compiler
control
in
the
same
place
that
form
our
options
are
located,
but
in
the
bill
train
on
the
source
stream,
but
that's
the
seeming
setup.
What
will
make
this
vertical
story
get
a
little.
D
B
B
So
what
I
was
just
trying
it
out
and
seeing
what
happens
when
you
do
this?
So
I've
got
two
different
options,
so
one
is
new
options
that
get
defined
in
the
command
line
and
then
the
officers
debug.
So
the
new
options
debug
does
is
that
it
takes
their
old
options
and
new
options
and
compares
them
and
then,
as
and
when
you
and
in
order
to
make
any
kind
of
option
wearing
you
use,
get
comp
option
and
then
provide
pointer
to
compilation
and
then
the
name
of
the
option
against
guess
process
this
way.
B
B
D
D
E
B
There's
going
to
be
added,
support
for
handling
non
boolean
type,
supporting
option
sets
and
supporting
setting
options
in
like
outside
of
compiler
options,
object
and
did
contact
being
the
one
that
is
of
concern
here
and
adding
support
for
using
this
new
option
mechanism
in
open,
g9
and
another
thing
is
migrating,
a
lot
of
the
options
that
we
have
that
are
specific
to
open
j9
in
all
merge
options,
JSON
few
options
of
JSON
in
origin,
I
yeah,
madam
and
more
in
the
future.
But
this
is
the
this:
is
the
immediate
plan
going
forward.
B
C
You
so
I'm
wondering
before
code
is
committed.
Is
there
a
way
to
prototype
the
performance
of
any
of
this
stuff,
because
I
would
hate
to
see
hundreds
of
hours
of
dev
work
going
into
building
something
to
then
have
a
major
performance
problem?
That
would
make
it
hard
for
open
j9
to
accept
the
new
mechanism
as
the
way
to
do
things,
because
we're
going
to
have
like
I
appreciate
that
there's
a
lot
of
thought
being
put
into
trying
to
do
things
the
right
way,
and
it
certainly
seems
that
you're
trying
to
be
careful.
B
Yeah
I
agree-
and
this
has
been
something
that
has
been
bothering
me
quite
a
bit
and
the
way
I
want
to
do.
It
is
I
want
to
complete
the
boolean
option,
support
within
one
bar
and
then
also
and
then
integrate
that
in
open
g9
and
perform
some
sort
of
benchmark
by
making
use
of
the
new
option,
plus
by
querying
the
new
options.
First
and
I
think
this
can
happen.
C
Resume
like
so
I
guess.
My
question
is:
why
do
we
need
to
commit
the
code
with
no
idea
about
the
performance
behavior
if
you've
got
most
of
what
you
need
for
the
boolean's?
Can't
you
just
do
a
prototype
of
what
it
would
look
like
and
get
the
performance
numbers
to
justify
that
this
is
the
right
way
to
go.
C
Because,
like
I'm,
not
an
OA
mark
emitter,
so
I
can't
hold
the
bar
for
four
omr
stuff,
but
for
most
of
the
open
j9
stuff
there
will
be
a
question
from
the
open
j9
community
about
the
performance.
It'll
have
to
be
a
discussion
about
it
and
I
I'm,
not
currently
aware
of
a
precedent
of
us
committing
code
with
no
expectation
of
what
the
performance
characteristics
are
going
to
be
so.
C
A
To
change
them
to
some
kind
of
a
macro,
yeah
or
or
something
at
those
sites
to
at
least
being
able
to
override
whatever
is
happening
there,
depending
on
how
you're
building
I,
don't
think
that
that
is
a
is
a
waste,
because
I
think
that,
like
I
said
it,
regardless
of
the
option
approach
room,
you
want
to
do
something
like
that
in
the
future.
So
you
can
I
think
go
throughout
the
code
phase,
certainly
through
Lamar
and
and
and
make
add
some
kind
of
I.
A
Don't
know
if
it
necessarily
has
to
be
a
macro
but
adds
something
in
all
those
places
to
make
it
easy
for
you
to
override
and
then
I
think
that
makes
it
easier
for
you
to
actually
do
that
kind
of
prototype
and
benchmarking
that
Andrew
is
asking
about
before
you
go
too
far
with
it,
because
I
think
that
I
mean
you've
done
most
of
the
work
already
to
actually
implement.
It
actually
get
this
into
a
table
right.
A
D
C
I
was
going
to
say,
I'm,
not
a
fan
of
having
a
macro
sprayed
throughout
the
code.
It
makes
it
harder
for
a
lot
of
IG
tools
to
know
the
right
thing.
To
do,
I
mean
there
is
the
get
option.
Can't
we
just
hide
all
of
that
macro.
Whatever
is
going
to
happen
in
there
inside
there
and
not
have
to
spray
the
whole
codebase
and
like
collide
with
changes
from
all
kinds
of
people
that
are
trying
to
get
stuff
into
the
compiler.
A
B
C
Is
what
I
dealt
with
it
because
right?
But
why
touch
the
whole
code
base
for
the
boolean
option
when
there
is
already
a
single
API?
You
can
just
change
the
implementation
of
that
API
and
then
you
don't
have
to
touch
the
code
base.
I
agree
that
some
of
the
accessors
may
be
more
complicated,
and
maybe
some
of
those
need
to
be
touched.
That'll
have
to
be
discussed,
but,
like
I,
don't
see
why
we
need
to
touch
the
whole
code
base
to
turn
what
was
seemingly
a
nice
simple
comp
get
option
into
a
macro.
That's
opaque.
C
B
I
think
we
could,
at
that,
get
option
method
to
handle
the
two
kinds
of
option:
query
mechanisms
yeah
so
anyway,
so
that
we
don't
really
have
to
use
the
macros
that
the
way
I
did
it.
There
was
just
one
way
of
doing
it,
where
I
found
a
way
to
enable
both
comparisons
and
lookup
of
the
old
versus
new,
but
obviously
that's
not
the
cleanest
one,
and
it's
a
it's
also
a
lot
of
work
trying
to
change
all
the
places.
That
is
that
the
options
get
quoted
from
it
is
much
easier
to
actually
change
the
function.
F
Remote
engine
off
the
top
of
my
head,
one
reason
just
putting
this
up
there
for
the
sake
of
completeness
and
because
information.
One
reason
the
macro
would
work
better
than
the
using
the
current
API
is
we're
changing
this
from
passing
in
a
int
field
or
an
end
to
grabbing
a
field
drug.
So
we
can't
just
we
could
try
using
say,
have
pointers
to
members
to
make
this
work,
but
it
there
might
be
some
subtlety
than
how
we
have
to
make
that
work.
If
we
want
to
preserve
the
current
API
I.
C
D
D
F
B
A
C
C
A
Another
thing
that
I
don't
think
you
mentioned
that
we
could
do
with
this
as
well,
is
that
we
could
actually
write
some
tests
for
it.
Some
relatively
straightforward
unit
tests,
they're
not
going
to
be,
you
know,
exhaustively
exhaustive
tests,
but
it's
better.
That's
certainly
miles
ahead
of
where
we
are
right
now,
with
how
the
options
are
actually
validated.
So
I
think
that
there
are.
There
are
opportunities
for
for
freighting
Sumida
tests
and
for
this
as
well.
D
D
Top
of
my
head.
I
can
see
aliases
option,
the
temple
can
option,
gets
deprecated
or
renamed
on
downstream
projects
to
keep
the
alias
alive
could
be
documented,
eternally
talking
as
a
home
are
or
I
guess,
open,
genuine
committer.
We
have
publicly
exposed
and
documented
options,
and
if
the
name
list
change
that
would
be
a
big
problem
process
shams
that
are
adding
alias
support
into
the
opportunity
and
a
couple.
Other
things
is
putting
help
and
documentation,
I'm,
not
sure
if
we've
decided,
whether
that's
an
all
more
thing
but
notice,
you
have
a
description
there.
Yes,.
B
D
D
B
Feature
X
will
be
true
or
false,
ideally
eventually
we'll
get
there,
but
right
now,
I'm
still
using
enable
and
disable
at
the
same
time
because
of
the
fact
that
we're
in
the
transition
phase,
but
eventually
it'll
be
just
a
boolean
field.
Determining
that
option
like
feature
X
enabled
yes
true
or
false,
so
that's
the
only
place
we'll
need
to
look
at.
C
B
C
B
B
C
But
so
take
an
optimization
right.
We
generally
have
an
option
per
optimization.
That
says,
we
want
to
be
able
to
turn
this
optimization
on
and
off
right
yeah.
At
the
moment,
99%
of
them
are
on
by
default,
which
means
that
there's
no
enable
option
in
the
current
table.
There's
a
disabled
right
and
the
there
are
some.
There
are
ones
that
are
in
development,
where
somebody
has
not
enabled
them
by
default,
and
so
there
is
no
disabled
but
there's
an
enable
in
the
table
and
it's
all
kind
of
asymmetric
and
and
yucky
right
and
when
somebody.
C
C
A
Camera
so
I
think
that
the
the
original
idea
that
was
proposed
many
months
ago
or
the
concern
that
was
raised
was
that
you're
really
just
describing
like
in
your
in
your
tailor,
but
you're
really
just
describing
the
feature
that
you're
interested
in
you're
not
actually
saying
enable
or
disable
that
you're
saying
this
is
a
boolean
feature.
It
can
be
on
or
off
yeah.
B
A
B
A
A
D
A
D
B
Don't
I
don't
think
there
should
be
issues
with
the
option,
data
types,
but
what
I
am
a
little
worried
about
would
be
handling
of
the
jet
config.
So
we'll
have
to
look
into
that.
I've
tried
moving
away
from
using
offset
of
operation
for
option
processing,
so
I'll
have
to
see
what
I
can
do
about
that.
Eventually,.
D
B
B
C
C
B
B
Yeah,
no,
they
will
be
generated
the
same
thing
it
used
to
be
different.
It
was
not
the
case
when
I
was
trying
to
come,
like
intelligence
may
determine
the
like
the
Associated
values,
with
the
characters
when
I
was
trying
to
make
a
perfect
hash
table,
and
that
was
resulting
in
a
different
table
each
time.
But
now
it
has
been
the
same
and
it
should
be
the
same
I
don't
see
any
reason
why
we
wouldn't
release
with.
D
The
hash
table
you
hear
both
though
right.
It's
the
layout
of
the
fields
in
the
options,
object,
I,
think
that
would
be
a
more
interesting
deterministic
right,
because
that's
a
thing
you're
likely
to
I
have
a
pointer
to
an
options,
object,
yeah,
no
way
of
decoding.
What
that
options
object
is
so
I
need
to
figure
out
which
boolean
field
it
is
that
I
care
about
yeah.
D
C
It
would
be
worse,
at
least
having
the
mental
thought
of.
If
you
all
you
had
is
a
core
image
of
the
compiler.
While
it
was
running,
how
would
you
figure
out
which
options
are
on
and
off
right
from
the
from
the
memory
image
me
right,
so
states
a
an
optimisation
crashes
right
and
we
want
to
go
and
see.
Okay.
Well,
was
this
thing
enabled
or
disabled,
because
it's
optional
right,
somebody
might
have
turned
it
on
or
not
so
then
we
want
to
go
and
ask:
what's
the
state
of
that
option?