Re: misc. links

[acken@informatik.uni-kl.de]

>  From: Guy Laden <laden@math.tau.ac.il>
>  ...
>  I've come across some new items that might be of interest when/if
>  we get to the stage where global optimization are an issue:
>  
>  http://www.cs.princeton.edu/~mff/ - contains links to a thesis titled: 
>  A Retargetable Optimizing Linker
>  ...
>  http://www.cmass.com/threads/1/threads.html#advanced
>  A (short) description of 'The Whole Program Optimizer', for Modula-3

It's actually quite simple to add global optimization to OOC.  GlobOpt
needs as input the code of some (if not all modules).  MFF's thesis
suggests to take the intermediate code as input (in our case this is
GSA).  So a possible scenario for GlobOpt is to compile all the
modules and transform them to GSA.  Then GlobOpt kicks in to work on
the collected code.  And finally give _all_ the GSA stuff to the
back-end.  This is a third kind of translation scheme: 
 - translation per module (that's currently done)
 - translation per procedure (as dicussed with Frank last week or so)
 - translation per program to do global optimization
The last is the most memory hungry of all, since it requires to have
the intermediate code of several modules in memory.

>  
>  . bottom-up tree rewriting tool MBURG, to be used for code selection
>    in compilers:
>  	http://www.dstc.qut.edu.au/~gough/sigplan.ps
>  	http://www.dstc.qut.edu.au/~gough/mburg07.ps
>    I'd like your opinions on using MBURG or a similar tool for generating
>    parts of the compiler's code-selection code.
>  
I scanned only the sigplan text.  I got the impression that it expects
some kind of syntax tree for input.  This program representation is a
far way of from our GSA, probably rendering this tool inadequate for
our project.  

-- mva