From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29369 invoked by alias); 23 Aug 2007 14:49:57 -0000 Received: (qmail 28102 invoked by alias); 23 Aug 2007 14:49:42 -0000 Date: Thu, 23 Aug 2007 14:49:00 -0000 Message-ID: <20070823144942.28101.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg01668.txt.bz2 ------- 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? 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. 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 ? Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136