------- Comment #12 from rguenth at gcc dot gnu dot org 2010-01-27 15:35
-------
In the testcase from comment #11 on trunk when translating PA_IN [7],
{ i_45 (0028), {[email protected]_46 (0007),
{component_ref<c3>,array_ref<i_45,0,4>,[email protected]_21 (0022), {plus_expr,i_45,1}
(0009) }
to block 20 we first translate
{component_ref<c3>,array_ref<i_45,0,4>,[email protected]_21
(0022) which is translated to
{component_ref<c3>,array_ref<i_45,0,4>,[email protected]_26
(0028). Later we translate i_45 (0028) to i_45 (0028), but when entering
that into the sets the value is already present.
Thus, this particular case is fixed by value-replacing the translated
expression in phi_translate_set.
But that does not sound like a proper solution. It looks more like an
issue of sorting. Though doing the value-replacement in case of
the translation being a name looks not too weird.
Danny? Is this something that should not happen because of some
constraints which are possibly violated?
Index: gcc/tree-ssa-pre.c
===================================================================
--- gcc/tree-ssa-pre.c (revision 156276)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -1834,12 +1834,20 @@ phi_translate_set (bitmap_set_t dest, bi
{
pre_expr translated;
translated = phi_translate (expr, set, NULL, pred, phiblock);
+ if (!translated)
+ continue;
/* Don't add empty translations to the cache */
if (translated)
phi_trans_add (expr, translated, pred);
- if (translated != NULL)
+ /* We might end up with multiple expressions from SET being
+ translated to the same value. In this case we do not want
+ to retain the NARY or REFERENCE expression but prefer a NAME
+ which would be the leader. */
+ if (translated->kind == NAME)
+ bitmap_value_replace_in_set (dest, translated);
+ else
bitmap_value_insert_into_set (dest, translated);
}
VEC_free (pre_expr, heap, exprs);
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dberlin at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42871
