https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106842
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Keywords| |missed-optimization,
| |wrong-code
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Huh.
static void
infer_loop_bounds_from_signedness (class loop *loop, gimple *stmt)
{
...
low = lower_bound_in_type (type, type);
high = upper_bound_in_type (type, type);
value_range r;
get_range_query (cfun)->range_of_expr (r, def);
if (r.kind () == VR_RANGE)
{
low = wide_int_to_tree (type, r.lower_bound ());
high = wide_int_to_tree (type, r.upper_bound ());
}
record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true);
and record_nonwrapping_iv verifies that the IV stays in [low, high]. So
this essentially means we are verifying range info here. We have
# RANGE [0, 9]
k_36 = PHI <k_20(18), 0(5)>
# RANGE [1, 9]
k_20 = k_36 + 1;
note the whole code is in a if (0) guarded block and we are executing
ranger_vrp, in the substitute and fold phase (IIRC the old [E]VRP avoided
to substitute/fold in dead code regions?).
somebody needs to double-check if the range on the stmts is wrong, but
depending on how VRP propagation treats unexecutable edges it might be
GIGO anyhow.
The "missed optimization" is that substitute-and-fold considers dead
regions. "wrong code" is because either the range is bogus or the
niter we derive from it is.
needs a second eye
