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