[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 #17 from dberlin at gcc dot gnu dot org  2007-08-23 13:45 -------
Subject: Re:  [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop

On 23 Aug 2007 12:13:13 -0000, jakub at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #16 from jakub at gcc dot gnu dot org  2007-08-23 12:13 -------
> But doesn't ipa_type_escape_field_does_not_clobber_p do what is documented?

I was there when it was written. It may be documented to do one thing,
but the intent was to do another :)

> At least for the uses in nonoverlapping_memrefs_p where
> ipa_type_escape_field_does_not_clobber_p is always called on some field, first
> argument is a DECL_FIELD_CONTEXT of some field ans second argument is its type.
> Then IMHO ipa_type_escape_field_does_not_clobber_p does the right thing.
It doesn't.
> 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.

>
> The ipa_type_escape_field_does_not_clobber_p call in may_alias_p is very
> different though.  Here we don't necessarily call it with some record (or
> union)
> type and a type of one of its fields, but rather with some record type (or
> pointer to it, pointer to pointer etc.) and some possibly completely unrelated
> other pointer type.  Well, because of previous
> if (!alias_sets_conflict_p (mem_alias_set, var_alias_set)) return false;
> it shouldn't be completely unrelated.  In most cases it will actually be the
> same
> type and that's something ipa_type_escape_field_does_not_clobber_p wasn't
> meant to answer.  I have instrumented may_alias_p, so that if
> ipa_type_escape_field_does_not_clobber_p returned false for reasons other than
> !initialized or !ipa_type_escape_type_contained_p, it would abort.
> The only testcase in the whole make check-{gcc,g++,gfortran} testsuite
> triggering this was gcc.c-torture/execute/builtins/pr22237.c, where var had a
> union type which contained ptr's type as one of its subfields.
>
> The whole use of ipa_type_escape_field_does_not_clobber_p in may_alias_p
> is very much unclear to me.

The whole *point* of ipa_type_escape was to be used in may_alias_p.
The use in alias.c was actually an afterthought.

> E.g.:
>               else if (ptr_star_count == 0)
>                 {
>                   /* If PTR_TYPE was not really a pointer to type, it cannot
>                      alias.  */
>                   alias_stats.structnoaddress_queries++;
>                   alias_stats.structnoaddress_resolved++;
>                   alias_stats.alias_noalias++;
>                   return false;
>                 }
> Isn't ptr guaranteed to be have POINTER_TYPE or REFERENCE_TYPE?

yes.

> Both from the
> way how is ->pointers array populated and e.g. that PTR_IS_REF_ALL is used
> before may_alias_p on the p_map->var resp. p_map1->var?  That implies
> ptr_star_count > 0, so the above listed chunk is never executed.

Also true.
> Also, as
> we don't care in the code whether ptr_star_count is 37 or just 1, I don't see
> the point in computing ptr_star_count at all, nor the existence of ptr_type
> variable.
>
> 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.

The other part of type-escape was to see if the address ever actually
escapes the CU, because if it does not, it could be transformed by
struct-reorg.

>   If
> ipa_type_escape_star_count_of_interesting_type (var_type) == 0, then
> ipa_type_escape_field_does_not_clobber_p call would make sense if ptr was
> a pointer to some field (field of field etc.), but then it needs to be called
> with TREE_TYPE (TREE_TYPE (ptr)) as second argument, otherwise it is asking
> a wrong question.

Also possible.  Kenny is not always good at knowing the intricacies of
our compiler.

> Please explain.


-- 


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