This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] New type-based aliasing (was: More CFG improvements)
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 06 Feb 2003 17:38:14 -0700
- Subject: Re: [tree-ssa] New type-based aliasing (was: More CFG improvements)
- Reply-to: law at redhat dot com
In message <20030207001037.GB6993@tornado.toronto.redhat.com>, Diego Novillo wr
ites:
>On Thu, 06 Feb 2003, Daniel Berlin wrote:
>
>> Fully pruned SSA form is probably not a good idea.
>> 1. It requires global liveness analysis
>> 2. There are plenty of examples of optimizations that are missed on
>> fully pruned SSA that aren't missed on semi-pruned or minimal.
>>
>I want to have the option of switching between semi-pruned and
>pruned. Some heuristic that says something like "oh, hell, no
>way we are inserting a gazillion PHI nodes in this graph".
And that is precisely what I am working on.
FWIW, using fully-pruned is only a 1% hit vs semi-pruned. Yup, that's
right, 1 freaking percent. For that one percent you get a compiler
that can actually handle things like 20001226-1.c with all of its
memory references disambiguated.
But knowing how near and dear this subject is to your heart, I've got
some heuristics to dynamically (on a per-variable basis) switch between
the two forms which actually results a compiler that is faster than
one that uses either form exclusively.
While that speed improvement (half a percent) is nice, what I like about
it is that it can handle ugly shit like 20001226-1.c without eating a
gig or more of memory.
>I had forgotten about #2, but now that you mention both Cytron
>and Briggs show the GVN example. I found references supporting
>having all three forms (IBM's Jikes RVM).
My recollection on this issue was that it works both ways. Sometimes
fully-pruned is better, sometimes semi-pruned is better from an
optimizer's standpoint.
But I'll take that loss of optimization opportunity in exchange for a
compiler that doesn't die when compiling big ugly code.
jeff