This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction
- From: Steven Bosschner <stevenb at suse dot de>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Steven Bosschner <stevenb at suse dot de>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>,Roger Sayle <roger at eyesopen dot com>, Jeff Law <law at redhat dot com>
- Date: Thu, 6 Nov 2003 18:50:23 +0100 (CET)
- Subject: Re: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction
- Organization: SuSE Linux AG
- References: <7123585.1068139442266.SLOX.WebMail.email@example.com><firstname.lastname@example.org>
On Nov 06, 2003 06:39 PM, Diego Novillo <email@example.com> wrote:
> On Thu, 2003-11-06 at 12:24, Steven Bosschner wrote:
> > So now we record (x == 5) in the avail_expr table and notice that u=27.
> > (Why is this test case called ssa-ccp anyway, this is a dominator opts testcase, really.)
> DOM is a family of optimizations. We do constant propagation, copy
> propagation and redundancy elimination of various types.
I'm just saying it would be better to scan the tree dom1 dump
then, instead of the ccp one, and rename the test case to
ssa-dom-1 or something like that.
> I'm not sure we want to be turning off folders blindly, though. We need
> a way of disabling some of these folders. Jason suggested on IRC that
> we could add a tree peephole pass at the end of the main optimization
> sequence that would catch these cases.
> That would mean separating the obfuscating folders and make them
> optional, or something. I'd like Roger or Jeff Law to comment on this
> problem, since they're more familiar with the folders.
Hmmm IMHO _all_ the folders are now obfuscated so it's hard to
tell which ones are obfuscating :-)
Seriously though, I agree, and I would have prefered to hide it
behind a flag or something, but we currently don't have anything
for that. Besides, I wanted to fix this test case to bring down
this large number of failures we have, and the folder the patch
turns off should really only happen on RTL, I think.
Perhaps we need to teach the folder about different compilation
phases (parsing, gimplifying, tree-optimizing, expanding, etc.)
and figure out which folder should (not) work in what phase???
(assuming someone first manages to clean up fold-const.c ;-)