Re: [PATCH] Make CCP effectively remove UNDEFINED defs

[Richard Biener <rguenther at suse dot de>]

On Wed, 4 Nov 2015, Marc Glisse wrote:

> On Wed, 4 Nov 2015, Richard Biener wrote:
> 
> > The following patch makes sure that CCP when it computes a lattice
> > value to UNDEFINED ends up replacing uses with default defs (and thus
> > removes such UNDEFINED producing defs).  This optimizes the testcase
> > below to
> > 
> >  <bb 2>:
> >  return _6(D);
> > 
> > in the first CCP.  Note this patch isn't mainly for the optimization
> > it does but for making it easier to discover cases where CCP gets
> > UNDEFINED wrong (similar to VRP2 re-using the range-info that is
> > still live on SSA names - that's to catch bogus range-info).
> > 
> > If the experiment works out (read: bootstrap / test completes
> > successfully) I'm going to enhance VRP and will also look at
> > how value-numbering could do a similar job.
> 
> Cool, the VN part might help with
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01556.html
> :-)

Actually it "breaks" gcc.dg/tree-ssa/pr44133.c as it transforms

  <bb 2>:
  _2 = l_1(D) + -22;
  _4 = _2 + s$i_5(D);
  return _4;

into

  <bb 2>:
  return _6(D);

turning the warning of an uninitialized use of s$i_5(D) (aka s.i)
into a warning of an uninitialized use of '({anonymous})'.

So I wonder if a better approach is to handle UNDEFINED differently
during propagation (now that we can propagate copies) and make
the value of _4 not UNDEFINED but a copy of (one of) the operand
that makes it undefined.  Thus we'd turn the above into

  <bb 2>:
  return s$i_5(D);

there is the chance that the warnings resulting from this will
be confusing (warning for an uninitialized use of sth far away
from its actual use).  Of course the above propagation is also
cheaper to implement (apart from the choice you have when
seeing x_1(D) + y_2(D) - which one do you pick and retain
the warning for?)

Anyway, a load of our testcases fail because they are now
optimized to nothing ... (fixing them right now).

Richard.