------- 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? 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. 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 where ptrA is struct A *, or &ptrA->i. Optimizations before ipa-type-escape will transform the former to the latter and if they don't, I believe check_cast will handle it anyway. The only problem in alias.c might be if exprx is COMPONENT_REF of the first field and expry is a var pointer to the whole struct A (or vice versa), then any taking of address of the whole struct anywhere would mean the MEMs could overlap. But in that case both MEMs will have different alias sets, don't they?
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. 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? 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, 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 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. But if ptr's type is the struct/union itself, all we care is if that record/union's address has been taken, which is not something ipa-type-escape won't answer. Isn't that what TREE_ADDRESSABLE can be used for? Please explain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136