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

[Massimiliano Mantione]

I resend this because in the previous message the patch was
uncompressed, and the message is waiting for moderation because
it's too large (note for moderator: kill previous message, this
one is updated and supersedes it).

So, like the subject says... this time SSAPRE is ready, and
(if there are no objections) I could really commit the code.

It passes *all* regression tests, which means I enabled SSAPRE
by default in driver.c and then I rebuilt the whole tree (both
mono and mcs).
After that, I executed the following:

make -C mcs/tests test-everything
make -C mcs/errors test-everything
make -C mono/mono/mini rcheck
make -C mono/mono/tests testjit

All gave "normal" results (there were issues in mcs/errors, but
Martin said it's OK, and a couple of things failed in the jit
test, but were not SSAPRE related and failed anyway without it).

I also have a nice benchmark result ;-)
Executing the attached program, the actual "computation" time
passes from 1.27s to 1.07s on my machine (see the code to see
what I mean by "computation").

While this is nice, keep in mind that in this first release it
is already a good result the fact that SSAPRE does not make things
*worse* :-)
There are a few issues I should still evaluate carefully (like
the fact that critical edges have bad interferences with branch
optimizations, too many variables are added on average, loop
invariant code motion is still suboptimal...
Also, some operations are still "missed": in the attached test,
just one "strlen" opcode is caught and moved out of a loop, but
there are other things that could have been handled, making the
result even better.

The compilation time of mscorlib.dll (mono --compile-all) goes
from about 1.56s with "-O=all,-ssapre" to 1.70s with "-O=all" (I
compared with 'all' instead of '-all' to have SSA in, otherwise
the comparison would not be fair).
It is worse (like it should be), but not that bad considering all
the work that SSAPRE must do.

Now about the code... I would especially like to see comments on
these things:

[1] The small modification I did in ssa.c, it looks safe, but I
    still haven't done a "svn blame" to see why that comment was
    there... anyway, removing the comment works ;-)
[2] I disable SSA when a method has arguments by reference, because
    this can lead to aliasing problems if the reference is passed
    forward to some other method (I found it the hard way, SSAPRE
    didn't work with aliasing).
[3] There is a "WARNING" log in ssapre.c when ssa.c did not put
    the definition bb in the def_bb field, my code puts it in, but
    why doesn't the SSA construction code do it in the first place?
    (I'm going to investigate this soon, but if anybody just happens
    to know...)

That's all...

Ciao,
  Massi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssapre.patch.gz
Type: application/x-gzip
Size: 15142 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041125/dc2e0c83/attachment.gz 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssapre-bench.cs
Type: text/x-csharp
Size: 1882 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20041125/dc2e0c83/attachment.bin