[PATCH] PR 10011: Introduce gcse_constant_p

[Roger Sayle]

On Sun, 30 Mar 2003, Richard Henderson wrote:
> This is ok, since it is a nice cleanup, but I don't think this is
> the whole story.  The real problem, as I see it, is that
> purge_builtin_constant_p is being run too late.
>
> In particular, what happens in each case is that we purge the
> constant_p_rtx, replace it with a zero, and then loop optimization
> moves the assignment out of the loop before the branch is simplfied.
> If we run this a bit ealier, then the post-gcse cse pass will take
> care of this.
>
> Indeed, this change by itself fixes both prs.
>
> 	* toplev.c (rest_of_compilation): Run purge_builtin_constant_p
> 	before post-gcse cse pass.
>

I have to disagree with you here, moving purge_builtin_constant_p
is just papering over the problem.  Your fix doesn't address the
example posted with my original solution.

void foo()
{
  int x = 100;
  int y = 20000;
  do {
    if (x > y)
      undef ();
  } while (x == 4);
}


Notice that GCSE is unable to optimize away the call to undef
on *some* platforms.  If this fundamental problem is fixed, we
can run purge_builtin_constant_p as late as previously, and even
take advantage that the argument may be constant due to loop peeling.

Your change of moving purge_builtin_constant_p just unfairly penalizes
targets where GCSE can eliminate dead-code, such as x86 Linux.  If it
helps support my argument I'll search for a testcase where __b_c_p
returned true previously, but now returns false with your change.
I'm sure I there'll be a good example in the Linux kernel :>

Roger
--