This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch]Follow-on for aliasing on vector replacements to match original





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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]