This is the mail archive of the 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] Work around for an unfortunate fold-const vs.tree-optimizer interaction

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.


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