From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-227835-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4244 invoked by alias); 24 Aug 2007 15:42:57 -0000
Received: (qmail 3556 invoked by alias); 24 Aug 2007 15:42:47 -0000
Date: Fri, 24 Aug 2007 15:42:00 -0000
Message-ID: <20070824154247.3555.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-33136-12956@http.gcc.gnu.org/bugzilla/>
Subject: [Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
In-Reply-To: <bug-33136-12956@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "dberlin at dberlin dot org" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2007-08/txt/msg01766.txt.bz2



------- Comment #21 from dberlin at gcc dot gnu dot org  2007-08-24 15:42 -------
Subject: Re:  [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop

On 24 Aug 2007 15:38:58 -0000, jakub at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #20 from jakub at gcc dot gnu dot org  2007-08-24 15:38 -------
> Created an attachment (id=14103)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103&action=view)
> gcc43-pr33136.patch
>
> Here is what I have been playing with.
> But I'd really like to see some testcases where the
> ipa_type_escape_field_does_not_clobber_p is supposed to help.
>
> I tried to write:
>
> /* PR tree-optimization/33136 */
> /* { dg-do compile } */
> /* { dg-options "-O2" } */
>
> struct S
> {
>   void *a;
>   int b;
>   float f;
> };
>
> static struct S s;
>
> static int *
> __attribute__((noinline, const))
> foo (void)
> {
>   return &s.b;
> }
>
> float
> __attribute__((noinline))
> bar (float *f)
> {
>   s.f = 1.0;
>   *f = 4.0;
>   return s.f;
> }
>
> int
> __attribute__((noinline))
> baz (int *x)
> {
>   s.b = 1;
>   *x = 4;
>   return s.b;
> }
>
> int
> t (void)
> {
>   float f = 8.0;
>   return bar (&f) + baz (foo ());
> }
> My understanding would be this is a perfect example where this optimization
> should help, ipa-type-escape-var analysis says
> ipa_type_escape_field_does_not_clobber_p (<struct S>, <void *>) == 1
> ipa_type_escape_field_does_not_clobber_p (<struct S>, <int>) == 0
> ipa_type_escape_field_does_not_clobber_p (<struct S>, <float>) == 1
> which is IMHO correct.  In the baz function, we aren't supposed to optimize
> out the read from s.b, as x may point to it (and in the testcase actually
> does).
> In bar on the other side, I believe we can optimize this to
> float
> __attribute__((noinline))
> bar (float *f)
> {
>   s.f = 1.0;
>   *f = 4.0;
>   return 1.0;
> }
> because as ipa-type-escap analysis found nothing ever takes address of any
> float field in struct S, so f can't point to it.
> But may_alias_p in that case is not called with var with struct S type (nor any
> pointer thereof), so ipa_type_escape_star_count_of_interesting_type will
> always return -1.  It is called just with STRUCT_FIELD_TAGs with float or int
> or void * type or f var_decl in function t.

The call to field_not_clobber_p needs to be in the call clobbering
functions (set_initial_properties and mark_aliases_clobbered) and
access_can_touch_variable to have any real effect.


-- 


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