[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (In reply to Jakub Jelinek from comment #0)
> > ... but then
> > comes dom2 and happily replaces
> >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> >   return _1;
> > with
> >   _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
> >   return  Inf;
> > (I think this is still correct)
> 
> Note this is also a pessimization code-generation wise since if we
> preserve the multiplication the result is readily available in a
> register but as optimized we have another constant pool entry and load.
> 
> So we might want to consider not propagating constants generated by
> operations
> we cannot eliminate.  If the only consumer is a compare-and-branch we
> can of course still end up with a seemingly dead stmt, so this would be only
> for the missed optimization.

[Sorry for the delayed response.  I've been on PTO.]

For the original testcase, the propagation happens in DOM:

  <bb 2> [local count: 1073741824]:
  _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0;
  return _1;

range_of_expr gets called on the return's _1 and correctly returns Inf, which
allows cprop_operand to do the replacement.

If I understand correctly you're suggesting not propagating constants that were
generated by an operation we can't eliminate.  In this case, it'd be easy to
chase the DEF back to the offending _1 definition (from cprop_operand and every
other places where we do propagations based on range_of_expr's result), but
ranger doesn't keep track of how it got to an answer, so we'd have to chase all
operands used to generate _1??  That'd get hairy pretty fast, unless I'm
misunderstanding something.

It really looks like the problem here is DCE (and the gimplifier as you point
out in comment #2), which is removing a needed statement.  Can't this be fixed
there?