[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop

["dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #19 from dberlin at gcc dot gnu dot org  2007-08-23 17:08 -------
Subject: Re:  [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop

On 23 Aug 2007 14:49:43 -0000, jakub at redhat dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #18 from jakub at redhat dot com  2007-08-23 14:49 -------
> Subject: Re:  [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
> in loop
>
> On Thu, Aug 23, 2007 at 01:45:11PM -0000, dberlin at dberlin dot org wrote:
> > > If you take address of the whole struct rather than some specific field and
> > > that address doesn't escape the CU, then that still doesn't explain how
> > > could a pointer var with first field's type point to the struct.
> >
> > > Say for
> > > struct A { int i; float f; } you still need (int *) ptrA
> >
> > Uh, no.
> >
> > &ptrA will do just fine. You can clobber all fields through it if it escapes.
>
> See "that address doesn't escape the CU" above I wrote.  But if so,
> it will be in global_types_full_escape and so
> ipa_type_escape_field_does_not_clobber_p will return false.
>
> > > If ipa_type_escape_star_count_of_interesting_type (var_type) > 0 (i.e. var is
> > > a pointer to struct/union rather than struct/union itself, how is the fact that
> > > something took address of fields within the struct itself relevant to whether
> > > some pointer may point to the pointer var or not?
> >
> > If the address was never taken anywhere, it can't be pointed to.
> > Type-escape tries to go a little further, and see if, when the address
> > of a field is taken, if that address is ever cast'd,
> > incremented/decremented, or escapes.  If not, then only that field is
> > clobbbered, not the entire structure.  Otherwise, it is equivalent to
> > calculating TREE_ADDRESSABLE.
>
> I was talking about say
> struct S { int i; float f; struct S **s1; struct S ***s2; struct S ****s3; };
> struct S ***var;
> struct S ****ptr;
>
> If we are asking whether
> may_alias (ptr, get_alias_set (TREE_TYPE (TREE_TYPE (ptr))), var, get_alias_set
> (var), false)
> then we are only interested in whether var is TREE_ADDRESSABLE,
> and this is IMHO exactly the same as asking in case of:
> void ***var;
> void ****ptr;
>
> But in the former case ipa_type_escape_star_count_of_interesting_type
> (var_type) == 3 and so we will call
> ipa_type_escape_field_does_not_clobber_p, in the latter case
> not.  How are these two different?

They aren't.

>
> In the c#8 testcase this is similar,
> ipa_type_escape_star_count_of_interesting_type (var_type) == 1,
> we have
> struct S *var;
> struct S **ptr;
> again, why does it matter if *var is a struct or not?  What matters
> is if var is TREE_ADDRESSABLE, if there is no &var, then it can't
> point to it, otherwise it can.  The same as for
> void *var;
> void **ptr;
>
> But if var isn't TREE_ADDRESSABLE, I'd bet nothing ever calls
> may_alias_p with it as third argument.

I'm not sure I believe that.   We probably still ask for globals anyway.

>
> So, do you agree the only case may_alias_p should handle with
> ipa_type_escape_field_does_not_clobber_p is
> ipa_type_escape_star_count_of_interesting_type (var_type) == 0 ?
Yes

It does look, however, that we should be using
field_does_not_clobber_p during call clobbering computation to avoid
clobbering entire structures when fields are clobbered (if possible).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136