Charles Oliver Nutter wrote:
Rubinius opcodes:
http://github.com/evanphx/rubinius/blob/ef93221a7049d72d28a46b97e1d7d69925166e9f/kernel/compiler/iseq.rb
First impressions:
* Rubinius's opcodes have a lot of too-low-level details for a proper
IR. The details of pushing and popping on the stack seem like they're a
detail to be left to the very last phases of compilation. So I think we
can ignore most of those.
* If we implement the IR as a DAG or CFG we would not represent gotos
directly either.
* Would local variables be an implementation detail? My very brief
reading of MacRuby code makes me think we'd want an abstraction over
variable assignment that's aware of its position in the hierarchy of
variable scopes, but not statically expecting it to be at a specific
depth or index. That would give us the option of inlining block logic
more easily, since we could easily rewrite the variable logic through a
transformation.
* Literals would probably be represented pretty much like they are now.
I would also like to open up the possibility of propagating what limited
type information we have through the IR, so that if you assign an array
to a variable and never re-assign it, we know it's a variable throughout
the code.
* Non-local flow control should be pulled out separate from local flow
control. So, if you have a return in a block, it should be represented
differently than a return in a method body. I think that would simplify
making determinations about how to optimize around non-local flow and/or
eliminate it during inlining.
* There doesn't appear to be any representation of frame access,
position information, thread scheduler pinging, and so on in the rbx
intermediate form. I feel more and more like we need to lift those
operations to the level of the IR, so we can see them and optimize them.
If we see, for example, that the IR has multiple position-updates in a
row, we can eliminate all but one. If we see that it multiple sets into
the frame will always be the same value, we skip doing the extra ones.
Only by lifting this to the IR can we see such things.
* On a similar token, having both static calls to core class methods and
dynamic calls to ruby methods represented in the IR would allow us to
optimize them better. If we make a static call to something we know
returns a String, we should be able to use that information for a
dynamic call...and possibly just make that a static call too. There's a
lot of type information present via literals, via making guesses and
assumptions about the methods we're calling (like expecting to_s to
return a String), and from the underlying static logic.
That's all for now. I'm going to give it more thought tonight and maybe
start drafting up my ideas for basic categories of operations
represented in a JRuby IR.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
