https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81403
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So this is during partial-PRE insertion where after PRE insertion of
Found partial redundancy for expression {bit_not_expr,_13} (0020)
Inserted _33 = ~_3;
in predecessor 5 (0014)
Created phi prephitmp_34 = PHI <_33(5), _8(6)>
in block 7 (0020)
we value-replace 0020 by prephitmp_34 and thus during partial-PRE
phi-translation
find, when translating _14 & 10393, _8 for _14 (0020) to be translated across
the edge exposing the range.
On the other edge we get from translating _14 & 10393 all the way to
translating
var_9.5_12 = var_9 as operand which leads us to var_9.1_2 = var_9 and
ultimatively
to _8 via "simplification" of ~_3 which has a leader of _33 (fine IMHO), but
unfortunately _33 has a value number of _8.
So PRE doing any insertion of a lexically equivalent expression will
necessarily
end up with a SCCVN value-number that might have range info that is not valid
there. Thus:
tree result = vn_nary_op_lookup_pieces (newnary->length,
newnary->opcode,
newnary->type,
&newnary->op[0],
&nary);
if (result && is_gimple_min_invariant (result))
return get_or_alloc_expr_for_constant (result);
expr = pre_expr_pool.allocate ();
expr->kind = NARY;
expr->id = 0;
if (nary)
{
PRE_EXPR_NARY (expr) = nary;
new_val_id = nary->value_id;
get_or_alloc_expression_id (expr);
}
needs adjustment to push away range-info.
