https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104288

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
its a bit more tightly intertwined than that unfortunately.  I had plans to
replace the current non-null processing with a range_after_stmt side-effect API
which would work in conjunction with dominator walks, but never got to it in
this release.

So ranger makes the assumption currently that if the non-null property is found
anywhere in the BB, it applies to the entire BB, unless
can_throw_non_call_exceptions is true, then it just bails.

The unfortunate side effect of this is we can no longer determine the
difference between this test case and (vrp111.c):


void foo (void *p) __attribute__((nonnull(1)));
void bar (void *p)
{
  foo (p);
  if (!p)
    __builtin_abort ();
}

where the use determining non-null happens first, and then we can eliminate
branches safely.  ie,so a problematic test case would be a combination:

void h(int result)
{
    if (result)
        __builtin_exit(0);
}
void foo (void *p) __attribute__((nonnull(1)));
void bar (void *p)
{
  h(p == 0);    // can't eliminate this
  foo (p);      // this makes p non=null
  if (!p)       // should be able to eliminate this
    __builtin_abort ();
}



I'm contemplating the situation.  The trick is to find something with minimal
change that is functionally acceptable.   I think the goal for this release
would be to continue to get vrp111.c, and simply not get it in the problematic
case..  ie, if the first use in the block is unknown and then LATER in the
block we figure out that it is non-null, we will miss that case through-out 
the block for now.  

Effectively: if no dominator block contains non-null then whatever the first
use in a block determines will apply to the whole block, for the duration of
the block.. but upon exit to the block, if it was non-null anywhere, then all
following blocks get that knowledge.  

I think this could be done reasonably efficiently with a minimum of risk/churn.
 At least that is what I'M currently trying.  would this be OK?

And for GCC 11 it is not much of an issue. Since it runs in hybrid mode, I can
simply switch ranger to be more pessimistic and deal with just dominators if
they are available, EVRP picks up the slack,  and it still pass all the
testsuite cases.

Reply via email to