https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com,
| |rguenth at gcc dot gnu.org
--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> r13-3923-g2f7f9edd28d75a85a33599978f23811e679e443d
>
> Note, I've just committed the PR107879 fix, but that one is for the reverse
> operations.
> And, we have still unresolved the PR107608 which on the other side could
> very well be related or the cause of this.
> BTW, Aldy, is there a way to disable all range related optimizations through
> some command line option? In the past, -fno-tree-vrp would do the trick,
> but now that the ranger is used in lots of passes, I don't know what else to
> use.
Not really, as ranger clients are spread around various passes.
I think you could return false from irange::supports_p() and
frange::supports_p() and that would block everyone using ranger. It would
certainly stop range_of_expr and range_of_edge, which are the main workhorses.
If this is needed, perhaps we could check some global flag from these functions
to provide a way to disable ranger. But I don't think it could be
-fno-tree-vrp because DOM uses ranger, but VRP is disabled for -O1. Perhaps
some internal --param flag if this is only needed internally?
Richi at one time suggested that we should probably formalize what we mean by
range propagation and document what we are and aren't allowed to do. Or
perhaps document that VRP might happen even for -fno-tree-vrp (as that's
definitely happening at -O1 through DOM's use of ranger (and previously evrp)).
