[patch]Follow-on for aliasing on vector replacements to match original
Dorit Naishlos
DORIT@il.ibm.com
Mon May 30 15:14:00 GMT 2005
I tested the patch on powerpc-apple-darwin (passed bootstrap with
vectorization enabled, and the vectorizer tests). The patch indeed fixes
the ssa-verify ICEs in SPEC (on powerpc-apple-darwin I had gcc, mesa and
fma3d failing with: "internal compiler error: tree check: expected
ssa_name, have var_decl in verify_ssa, at tree-ssa.c:750". These are fixed
with this patch! )
FYI, There are 3 open PRs related to this problem:
- PR21653: was fixed by the first part of your patch (at least as far as I
can see on powerpc-apple-darwin).
- PR21155: the ssa-verify ICEs reported there may be fixed by this patch.
- PR21789: I think this is also fixed by this patch.
> tested on ppc it fixes a verify_ssa error in SPEC gcc reload1.c
>
If you happened to extract a small testcase from this, would be nice to add
it to the testsuite.
> The patch includes the entire procedure new_type_alias because it is a
new
> procedure in a patch that has yet-to-be committed. See
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02462.html.
>
After committing your first patch, looks like this is the diff for this new
fix:
Index: tree-ssa-alias.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.93
diff -c -3 -p -r2.93 tree-ssa-alias.c
*** tree-ssa-alias.c 29 May 2005 13:14:42 -0000 2.93
--- tree-ssa-alias.c 30 May 2005 10:10:11 -0000
*************** found_tag:
*** 2776,2782 ****
}
! /* Create a type tag for PTR. Construct the may-alias list of this type
tag
so that it has the aliasing of VAR. */
void
--- 2776,2782 ----
}
! /* Create a new type tag for PTR. Construct the may-alias list of this
type tag
so that it has the aliasing of VAR. */
void
*************** new_type_alias (tree ptr, tree var)
*** 2798,2809 ****
if (var_can_have_subvars (var)
&& (svars = get_subvars_for_var (var)))
{
! subvar_t sv;
for (sv = svars; sv; sv = sv->next)
add_may_alias (tag, sv->var);
}
else
! add_may_alias (tag, var);
/* Note, TAG and its set of aliases are not marked for renaming. */
}
--- 2798,2827 ----
if (var_can_have_subvars (var)
&& (svars = get_subvars_for_var (var)))
{
! subvar_t sv;
for (sv = svars; sv; sv = sv->next)
add_may_alias (tag, sv->var);
}
else
! {
! /* The following is similar to code in add_stmt_operand so that
replacing
! a reference to var with an INDIRECT_REF to ptr will append the
same
! defs and uses. */
! varray_type aliases = v_ann->may_aliases;
!
! if (aliases == NULL)
! add_may_alias (tag, var);
! else
! {
! /* FIXME, if aliases has just one member mbr which satisfies
! get_var_ann (mbr)->mem_tag_kind == TYPE_TAG then should
! p_ann->type_mem_tag be set to mbr (and avoid the call to
! create_memory_tag)? */
! size_t i;
! for (i = 0; i < VARRAY_ACTIVE_SIZE (aliases); i++)
! add_may_alias (tag, VARRAY_TREE (aliases, i));
! }
! }
/* Note, TAG and its set of aliases are not marked for renaming. */
}
thanks,
dorit
> This patch continues the effort to have new_type_alias (ptr, var) create
a
> type tag
> for ptr whose aliasing matches that of var. The addition in this patch
> looks for
> a may_aliases list in the var_decl var and if found creates a duplicate
> list for the
> may_aliases of the newly created type tag. Otherwise when var has an
> empty
> may_aliases list then the new type tag gets a may_aliases list of just
> var.
>
> The patch includes the entire procedure new_type_alias because it is a
new
> procedure in a patch that has yet-to-be committed. See
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02462.html.
>
> tested on ppc it fixes a verify_ssa error in SPEC gcc reload1.c
>
> OK for mainline?
>
> Keith
>
> Changelog:
>
> 2005-05-26 Keith Besaw <kbesaw@us.ibm.com>
>
> * tree-ssa-alias.c (new_type_alias): If the variable
> has a may_aliases list then duplicate it for the
> may_aliases list of the new type tag.
>
> Index: tree-ssa-alias.c
> ===================================================================
> RCS file: /cvsroot/gcc/gcc/gcc/tree-ssa-alias.c,v
> retrieving revision 2.92
> diff -u -3 -p -r2.92 tree-ssa-alias.c
> --- tree-ssa-alias.c 24 May 2005 19:57:52 -0000 2.92
> +++ tree-ssa-alias.c 26 May 2005 07:27:10 -0000
> @@ -2776,6 +2776,57 @@ found_tag:
> }
>
>
> +/* Create a new type tag for PTR. Construct the may-alias list of this
> type tag
> + so that it has the aliasing of VAR. */
> +
> +void
> +new_type_alias (tree ptr, tree var)
> +{
> + var_ann_t p_ann = var_ann (ptr);
> + tree tag_type = TREE_TYPE (TREE_TYPE (ptr));
> + var_ann_t v_ann = var_ann (var);
> + tree tag;
> + subvar_t svars;
> +
> + gcc_assert (p_ann->type_mem_tag == NULL_TREE);
> + gcc_assert (v_ann->mem_tag_kind == NOT_A_TAG);
> + tag = create_memory_tag (tag_type, true);
> + p_ann->type_mem_tag = tag;
> +
> + /* Add VAR to the may-alias set of PTR's new type tag. If VAR has
> + subvars, add the subvars to the tag instead of the actual var. */
> + if (var_can_have_subvars (var)
> + && (svars = get_subvars_for_var (var)))
> + {
> + subvar_t sv;
> + for (sv = svars; sv; sv = sv->next)
> + add_may_alias (tag, sv->var);
> + }
> + else
> + {
> + /* The following is similar to code in add_stmt_operand so that
> replacing
> + a reference to var with an INDIRECT_REF to ptr will append the
> same
> + defs and uses. */
> + varray_type aliases = v_ann->may_aliases;
> +
> + if (aliases == NULL)
> + add_may_alias (tag, var);
> + else
> + {
> + /* FIXME, if aliases has just one member mbr which satisfies
> + get_var_ann (mbr)->mem_tag_kind == TYPE_TAG then should
> + p_ann->type_mem_tag be set to mbr (and avoid the call to
> + create_memory_tag)? */
> + size_t i;
> + for (i = 0; i < VARRAY_ACTIVE_SIZE (aliases); i++)
> + add_may_alias (tag, VARRAY_TREE (aliases, i));
> + }
> + }
> +
> + /* Note, TAG and its set of aliases are not marked for renaming. */
> +}
> +
> +
> /* This structure is simply used during pushing fields onto the
> fieldstack
> to track the offset of the field, since bitpos_of_field gives it
> relative
> to its immediate containing type, and we want it relative to the
> ultimate
>
More information about the Gcc-patches
mailing list