Re: [PATCH] PR 10011: Introduce gcse_constant_p

[Roger Sayle <roger at www dot eyesopen dot com>]

On Sun, 30 Mar 2003, Richard Henderson wrote:
> On Sun, Mar 30, 2003 at 03:56:05PM -0700, Roger Sayle wrote:
> >
> > void foo()
> > {
> >   int x = 100;
> >   int y = 20000;
> >   do {
> >     if (x > y)
> >       undef ();
> >   } while (x == 4);
> > }
>
> And what does this have to do with __builtin_constant_p?

It's distilled from test case gcc.c-torture/execute/20010119-1.c.
Because that testcase contains __builtin_constant_p it is often
mistakenly assumed that its a failure of __builtin_constant_p.
In actually, removing the __builtin_constant_p completely results
in a test case that still fails on many targets, PA risc, h8300,
etc...

The purge_builtin_constant_p implementation is based upon the
assumption that atleast one pass after purge_builtin_constant_p
is able to perform dead code elimination.  Normally, such as on
alpha and x86, this is the bypass pass, but if that fails
the dead-code remains.  The code in PR 10011 is valid, it just
contains a dead call to a potentially non-existant function.

In many cases, including PR 10011, fixing the example quoted
above, which tests bypass' ability to eliminate dead-code
also cures the problem attributed to __builtin_constant_p.


I give you full credit that reordering gcse-cse-purge-loop-bypass
to gcse-purge-cse-loop-bypass is an inspired fix to PR 10011.
This allows cse to propagate the results of the purge into the
conditional jumps before they get split/obfuscated by loop.  As
you can see my fix to improve bypass' ability to handle condition
code setters in different basic blocks is much more complex.

And try as I might I haven't yet been able to come up with a case
where the CSE pass immediately before the purge is able to propagate
a constant into __builtin_constant_p.  I was also completely wrong
about determining constants from loop optimizations, we've already
committed __builtin_constant_p before we reach loop.


Please forgive my ignorance.  I don't think I've won an argument
against you yet, but I've learned a great deal from each attempt :>

Roger  "Sourcerer's apprentice"
--