From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31168 invoked by alias); 23 Aug 2007 17:09:20 -0000 Received: (qmail 26440 invoked by alias); 23 Aug 2007 17:08:46 -0000 Date: Thu, 23 Aug 2007 17:09:00 -0000 Message-ID: <20070823170846.26439.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: "dberlin at dberlin dot org" 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/msg01674.txt.bz2 ------- 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 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