[Mono-devel-list] SSAPRE: this time it's for real ;-)

[Massimiliano Mantione]

On Thu, 2004-11-25 at 21:33, Willibald Krenn wrote:
> Thanks for the list. Looks like transformations on SSA form are not 
> number one priority.. Does that mean computing SSA is considered to be 
> too much overhead?

I think the general feeling now is that SSA based optimizations
are more for AOT compilation (and in fact they are not turned on
by default).
Or, when we'll have on line profiling, we could recompile methods
which are "hot" with more aggressive optimizations (there is work
in that direction... that was just *my* todo list!).

>  >- Copy propagation (without SSA).
>  >- Dead code elimination (without SSA).
> [...]
> I was under the impression that these optimizations are already included 
> and working. Guess I have to look again.

Included, yes, but there is work to do.
Quite honestly, I'd have to look at the code to tell you exactly
*what* is wrong there :-(

> Any plans about virtual function inlining (e.g. Paper of Kazuaki Ishizaki)?

Not in the near future (anyway, not that I know of).
This does not mean that nobody is thinking about it... there are
simply other things to do before, both in terms of priority, and
in terms of prerequisites to make it feasible.

For instance, that form of inlining can take place only "late"
in the optimization pipeline, after you have analyzed the code and
have inferred the types of the objects whose method calls will be
made "static" instead of virtual, so that they can be inlined.
One issue (at least, IMHO) is that inlining changes the CFG, and
with it the dominator tree, the [iterated] dominance frontiers...
At that stage of the compilation there are passes that depend on
those data structures, which should therefore be recomputed.
Otherwise, it would be nice to have them stored in a different way
more suited to be updated dynamically (there are papers describing
things like this).
By the way, having such a thing would help in dealing with critical
edges as well... now what I do is remove *all* critical edges at
the beginning of the compilation, simply because I cannot add BBs
in the middle of it (I mean inside SSAPRE).
This is a (small?) waste of time and memory, and then I must hope
that the second pass of branch optimizations at the end will clean
things up (which it does not, at least not completely).
Being able to add BBs at any point in the compilation (and having
the dominator information and iterated dominance frontiers updated
at a low cost) would be cleaner, more practical, and probably also
more efficient, but now things do not work that way.

This just to say "maybe yes, but later"...

Ciao,
  Massi