------- 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 <[EMAIL PROTECTED]> 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