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

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #12)
> (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.

Yes, the fact that ranger doesn't operate as a usual propagator with a lattice
makes things very difficult here.  Note that my comment referred to code
optimality, not correctness.

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

Sure it can, but the expense is that we'd do constant folding all the way
down and not remove dead code which will result in _tons_ of unnecessary
constant pool entries and loads.

The issue is also that -ftrapping-math is default on so we'd have to
do this by default.  Ugh.

Note that the constant folding routines generally refrain from folding
when that loses exceptions, it's just ranger when producing singleton
ranges and propagating from them that doesn't adhere to that implicit rule.