[Mono-devel-list] SSAPRE news
vargaz at gmail.com
Wed Dec 1 15:38:50 EST 2004
I think it should be checked in, whenever it works or not, so
others can see it etc.
On Wed, 01 Dec 2004 16:12:40 +0100, Massimiliano Mantione
<massi at ximian.com> wrote:
> 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...
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list