http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55107
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |55629
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-10
12:13:54 UTC ---
The issue is shown by:
Index: tree-ssa-pre.c
===================================================================
--- tree-ssa-pre.c (revision 194345)
+++ tree-ssa-pre.c (working copy)
@@ -867,6 +867,8 @@ bitmap_set_replace_value (bitmap_set_t s
return;
}
}
+
+ gcc_unreachable ();
}
that is, we have a value in NEW_SETS,
(gdb) call debug_bitmap_set (set)
debug[0] := { prephitmp_61 (0036), prephitmp_74 (0056), prephitmp_29 (0057),
prephitmp_62 (0046), prephitmp_6 (0047), prephitmp_73 (0029) }
(gdb) p lookfor
$1 = 29
that is not in value_expressions:
0029[0] := { d.7_35 (0029), {nop_expr,d_25} (0029),
{mem_ref<0B>,addr_expr<&a>}@.MEM_36 (0029), prephitmp_83 (0029) }
That happens because we re-set prephitmp_73's value from its original 37
to 29 in do_regular_insertion but do not adjust value_expressions.
In fact,
/* If all edges produce the same value and that value is
an invariant, then the PHI has the same value on all
edges. Note this. */
else if (!cant_insert && all_same && eprime
&& (edoubleprime->kind == CONSTANT
|| edoubleprime->kind == NAME)
&& !value_id_constant_p (val))
{
unsigned int j;
bitmap_iterator bi;
bitmap exprset = value_expressions[val];
unsigned int new_val = get_expr_value_id (edoubleprime);
EXECUTE_IF_SET_IN_BITMAP (exprset, 0, j, bi)
{
pre_expr expr = expression_for_id (j);
if (expr->kind == NAME)
{
vn_ssa_aux_t info = VN_INFO (PRE_EXPR_NAME (expr));
/* Just reset the value id and valnum so it is
the same as the constant we have discovered. */
if (edoubleprime->kind == CONSTANT)
{
info->valnum = PRE_EXPR_CONSTANT (edoubleprime);
pre_stats.constified++;
}
else
info->valnum = VN_INFO (PRE_EXPR_NAME
(edoubleprime))->valnum;
info->value_id = new_val;
}
}
looks like a hack that while adjusting all existing name(!)
expressions for a value it does not adjust bitmap sets. What it seems to
try to do is unify two value-ids after-the-fact.
We cannot get this "right" this way. We simply have to perform PHI
insertion to "merge" the values.
The above is a hack around the inability of the value-numbering to handle
this case (see PR55629). But it's not a sustainable solution as this
bug shows ...
I have a patch.
