Hi Noah,
Thanks for the thoughts and the hack!
On Sat 23 Jun 2012 16:03, Noah Lavine <noah.b.lav...@gmail.com> writes:
> It looks to me like the GLIL->assembly compiler spends most of its
> effort building constant tables, which I believe the RTL assembler
> does in the rtl branch.
The other things that it does, for the record:
1) Allocate variable cache cells. Related to the constant table, so
perhaps the assembler can take care of this.
2) Assembling the "meta" procedure. Given that the debugging will be
significantly different in the rtl branch, again the assembler might
be able to understand inline debugging macro-instructions.
3) Some instruction selection, based on whether the indexes of
variables are in range or not. Again, the assembler can do this.
So yes, I guess you are right.
Here are some things that I would like to be able to do, that we can't
do yet easily:
1) Reorder basic blocks. We should be able to do a topological sort of
the blocks based on the dominator tree, and put cold blocks like
bailouts at the end of a function.
2) Simplify the control-flow graph. Sometimes we have blocks that
basically just jump to another block without doing anything. We
need to be able to reason about jumps. We also need to be able to
turn two-jump loops into one-jump loops.
3) Fix order of evaluation. A lower-level transformation could do
that: either to CPS/ANF in Tree-IL itself, or to SSA.
4) Loop optimizations. For example, loop peeling: unrolling the first
round through a loop can let CSE do a great job in the loop. Loop
peeling + CSE is basically LICM.
All of these things seem to indicate that we need some changes to
Tree-IL. I don't know exactly what though, and this is something we can
work on after having a working tree-il->rtl compiler.
As food for thought, I really liked Kennedy's "Compiling with
Continuations, Continued" paper:
http://research.microsoft.com/pubs/64044/compilingwithcontinuationscontinued.pdf
Happy hacking,
Andy
--
http://wingolog.org/
