This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] New type-based aliasing (was: More CFG improvements)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]