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

[Willibald Krenn]

Massimiliano Mantione schrieb:
>> 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!).

Who is working on that, if I may ask? The reason is that I'm just 
preparing to do something in that area too.. But then again, I'll try to 
combine this with a custom (AMD64) backend - so I'm not really sure how 
this will fit into Novell's plans...
Albeit, I could probably help in doing some basic work for online 
profiling as this should also benefit my own 'try'..

Is there some information available describing what you plan to do rsp. 
what has to be done in terms of changes to the basic mono-system?

>> >- 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 :-(

Oh, that doesn't sound good!

I hope you have fixed the problems by the time I need these 
functionality in my mono-hack.. ;-)

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

I just realized that this paper describes _devirtualization_ - which 
doesn't inline the method ...


> 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).

Seems I still have to get a better understanding of mono source..


> 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).

Hmm, this is very unfortunate, because not being able to change the CFG 
by adding / moving(?) BBs means lots of optimizations can't be applied, 
right? I guess Splitting falls into this category?



> 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.

Do you have any paper reference handy?


Thanks for your very informative answer!

It was very much appreciated,
  Willi