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: Diego Novillo <dnovillo at redhat dot com>
- To: Steven Bosschner <stevenb at suse dot de>
- Cc: "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, 06 Nov 2003 12:39:53 -0500
- Subject: Re: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction
- Organization: Red Hat Canada
- References: <7123585.1068139442266.SLOX.WebMail.firstname.lastname@example.org>
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.
> Ideas? OK for now? (booted-'n-tested on powerpc64)
I have a similar situation in my local tree. The folder is replacing a
conditional of the form (a.b || a.c || a.d) into a BIT_FIELD_REF
operation. This is obfuscating the code enough that the tree optimizers
aren't able to reduce the function to 'return 0;' (as they would if the
folder didn't try to optimize this).
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.