[Mono-devel-list] SSAPRE news

Massimiliano Mantione massi at ximian.com
Wed Dec 1 10:12:40 EST 2004

First, some good news: the issue my code had with loop invariants
is gone, and with it the workaround I applied to "cover" it :-)
This means that now SSAPRE is correctly applied to all loop
invariants, and the resulting code performs even better!

Then, a question for jit hackers...
I finally noticed that SSAPRE and consprop|copyprop don't work
together (and in fact this was expected, since SSAPRE doesn't like
"messed up" SSA, and copyprop can easily produce it).

I then tried to apply consprop|copyprop after SSAPRE (only when
SSAPRE is enabled, otherwise everything stays as it is).
To my surprise, consprop|copyprop were still fairly effective, but
the issue did not go away :-(
By the way, the issue happens in the "even-odd" regression test.

I still haven't investigated what is *actually* happening... I
tried to force consprop|copyprop disabled when SSAPRE is enabled,
but the obvious result is that performance suffers badly.

It might take me a lot to fix this thing, but in the meanwhile
would it be OK to commit SSAPRE anyway, but leaving it disabled
by default (even if somebody uses '-O=all')?

Or, alternatively, I could force SSAPRE disabled when one of
consprop|copyprop is present.

What do you think?
And, by the way, when could I commit SSAPRE?
(still no comments on the patch so far... I wanted to commit as
soon as I have finished documenting it)

One last thing: I am commenting the source, but in most cases the
real explanation is in the SSAPRE paper. Only, it is often not
obvious *which* piece of the paper has the explanation (unless one
knows the paper very well, and in that case most of the comments
would be pointless anyway).
Would it make sense, where I do not deviate from the paper (95%
of the code) but things are not obvious (a lot of places), to just
put "pointers" to the paper in the comments?
Something like "/* See section x.y.z, the paragraph about foo */".
I know this sounds strange, but that paper is in any case a required
reading to understand the code...


More information about the Mono-devel-list mailing list