[PATCH] Make CCP effectively remove UNDEFINED defs

[Richard Biener]

On Wed, 4 Nov 2015, Richard Biener wrote:

> 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?)

Ok, it's actually _not_ easy.  The operand might not have the
correct type after all and we'll introduce a not fully propagated
lattice that way (the 'copy' value would have a lattice value
of UNDEFINED).

Richard.