https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #24 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #21)
> (In reply to Richard Biener from comment #13)
>
> > 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.
> >
>
> I think I'm missing something, or not understanding what you are saying.
>
> Why is the propagation or lack of lattice a problem? Its DCE that is
> removing that potentially trapping stmt because its no longer used in the
> IL? THe change would be to not kill off dead statements that may trap? I
> guess this may leave a bunch of feeding statements that are not dead.. but I
> fail to see how thats different than not propagating and then not being able
> to delete those stmts either?
>
>
> > 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.
>
> I'm also not sure what this means. I don't think ranger itself propagates
> singleton constants.. VRP is still using the substitute_and_fold engine, so
> any folding/propagation is still going through the same mechanisms we always
> did when a singleton result is produced. We just produce more of them now,
> especially with floats. I don't think ranger is doing anything different
> than VRP ever did regarding propagation. Its possible GCCs infrastructure
> for dealing with float propagation isn't mature enough perhaps?
Right, ranger isn't propagating anything. It's the substitute_and_fold engine,
as it always has, but only if value_of_expr() is non-NULL. Currently this
function will only return non-NULL for singletons:
tree
range_query::value_of_expr (tree expr, gimple *stmt)
{
tree t;
if (!Value_Range::supports_type_p (TREE_TYPE (expr)))
return NULL_TREE;
Value_Range r (TREE_TYPE (expr));
if (range_of_expr (r, expr, stmt))
{
// A constant used in an unreachable block oftens returns as UNDEFINED.
// If the result is undefined, check the global value for a constant.
if (r.undefined_p ())
range_of_expr (r, expr);
if (r.singleton_p (&t))
return t;
}
return NULL_TREE;
}
