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: PING: PR26197 (new_type_alias) fix


Daniel Berlin <dannyb@google.com> wrote on 08/08/2006 11:14:27 AM:

> Dorit Nuzman wrote:
> > Daniel Berlin <dannyb@google.com> wrote on 07/08/2006 07:51:40 PM:
> >
> >> This is fine, thanks (though part of me wonders if it should only be
the
> >> way you describe *when* grouping has taken place, instead of always,
but
> >> you bootstrapped and tested it, so ...)
> >>
> >
> > well, I bootstrapped without vectorization enabled, so I don't think
this
> > code was ever activated during bootstrap. I will bootstrap with
> > vectorization enabled before I commit the patch.
> >

The patch passed bootstrap with vectorization enabled on i686.

> > What do you meen by grouping?
>
> So before the code did
>
>   TAG <- new tag for ptr;
>    if (var has subvars){
>       foreach subvar
>         add the subvar as may-alias of TAG.
>    }
>    else{
>       get the may-aliases of var;
>       if (|may-aliases| == 1)
>         set the (single) may-alias of var as the new tag of ptr;
>       else if (|may-aliases| == 0)
>         add var as may-alias of the TAG;
>       else /* |may-aliases| > 1 */
>         add the may-aliases of var as may-aliases of TAG;
>    }
> and now does
>
> TAG <- new tag for ptr;
>    if (var has subvars){
>       foreach subvar
>         add_may_aliases_for_new_tag (TAG, subvar)
>    }
>    else{
>       add_may_aliases_for_new_tag (TAG, var)
>    }
>
>    add_may_aliases_for_new_tag (TAG, var)
>    {
>       get the may-aliases of var;
>       if (|may-aliases| == 1)
>         set the (single) may-alias of var as the new tag of ptr;
>       else if (|may-aliases| == 0)
>         add var as may-alias of the TAG;
>       else /* |may-aliases| > 1 */
>         add the may-aliases of var as may-aliases of TAG;
>    }
>
>
> The difference between the two is that you used to add the subvars to
> the tags, and now you add the the aliases of the subvars, presumably
> because your subvars are marked as tags (what is now known as
> "is_aliased" as of late).
>
> The main reason subvars get marked as tags is because of
> 1. It is the target of some aliasing relationship
>
> 2. The alias grouping code, which ends up putting tags in the may-alias
> list of other tags.
>
> if is_aliased is false on the subvars when you start new_type_alias, but
> becomes true during it, it means you are adding subvars to a tag that
> were never aliases of anything else before (or else they would have had
> is_aliased set by add_may_alias).
>
> I'm not sure why you'd want to do this in case #1 *if is_aliased was
> false* (unless you also just created those subvars, too), because if
> they aren't part of an aliasing relationship, we had already determined
> them to be not touched by a dereference.
>
> It is nuclear from the comments on the bugreport whether it was false
> before new_type_alias started or not.
>

In the testcase, the is_aliased of the subvar in question is false... So,
if I do the following instead of the above (i.e. change the behavior only
if is_aliased is true), the test fails:

if (var has subvars){
      foreach subvar
        if (subvar->is_aliased)
          add_may_aliases_for_new_tag (TAG, subvar) /* new behavior */
        else
          add the subvar as may-alias of TAG /* old behavior */
   }
   else{
      add_may_aliases_for_new_tag (TAG, var)
   }

So for some reason this change is needed even when the subvar is not marked
as is_aliased.

thanks,

dorit

> In case #2, you have to do what you are doing because, as diego says in
> comment 12, the grouping code plays with what the definitions of tags
> and aliases are so that tags can be aliases of other tags.
>
> --Dan


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