https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119683
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amacleod at redhat dot com,
| |jakub at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed, before r13-3596 vrp1 was able to fold
<bb 3> [local count: 365072224]:
_3 = (int) c_12(D);
- _4 = _3 + -48;
- _15 = (unsigned int) _4;
+ _26 = c_12(D) + -48;
+ _4 = (int) _26;
+ _15 = (unsigned int) _26;
given int[48, 57] range of signed char c_12(D) on the 2->3 edge.
I think the pre-ranger VRP was rewriting SSA_NAMEs in the IL to use bb local
temporary variants of those with different ranges, so the
/* ((T)(A)) + CST -> (T)(A + CST) */
match.pd's rule
int_range_max vr;
if (get_global_range_query ()->range_of_expr (vr, @0)
&& !vr.varying_p () && !vr.undefined_p ())
was actually seeing the local bb range (here of c_12(D)'s variant which didn't
have VARYING but int[48, 57] range) but with execute_ranger_vrp that isn't
happening anymore, we'd need to call range_of_expr (vr, @0, stmt) with the
right stmt and perhaps a different query.
Except I think generally figuring out what is the current stmt in match.pd is
hard and problematic. But maybe at least arrange when the simplifiers are
invoked from rvrp_folder::fold_stmt on a particular stmt and the operands match
that exact statement there could be some way to query the local range on that
stmt rather than the global range?
