public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dberlin at dberlin dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
Date: Fri, 24 Aug 2007 15:42:00 -0000	[thread overview]
Message-ID: <20070824154247.3555.qmail@sourceware.org> (raw)
In-Reply-To: <bug-33136-12956@http.gcc.gnu.org/bugzilla/>



------- 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


  parent reply	other threads:[~2007-08-24 15:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-21 12:23 [Bug regression/33136] New: -Os generated code grew almost twice 4.2.1 versus 4.1.1 vda dot linux at googlemail dot com
2007-08-21 12:24 ` [Bug regression/33136] " vda dot linux at googlemail dot com
2007-08-21 12:26 ` vda dot linux at googlemail dot com
2007-08-21 12:27 ` vda dot linux at googlemail dot com
2007-08-21 13:11 ` rguenth at gcc dot gnu dot org
2007-08-21 13:12 ` [Bug tree-optimization/33136] [4.2/4.3 Regression] " rguenth at gcc dot gnu dot org
2007-08-21 16:20 ` pinskia at gcc dot gnu dot org
2007-08-22 13:27 ` jakub at gcc dot gnu dot org
2007-08-22 13:55 ` jakub at gcc dot gnu dot org
2007-08-22 13:57 ` jakub at gcc dot gnu dot org
2007-08-22 14:20 ` rguenth at gcc dot gnu dot org
2007-08-22 14:29 ` jakub at gcc dot gnu dot org
2007-08-22 15:15 ` [Bug tree-optimization/33136] [4.1/4.2/4.3 " rguenth at gcc dot gnu dot org
2007-08-22 15:53 ` [Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop dberlin at gcc dot gnu dot org
2007-08-22 17:24 ` jakub at gcc dot gnu dot org
2007-08-22 20:10 ` dberlin at gcc dot gnu dot org
2007-08-23 12:13 ` jakub at gcc dot gnu dot org
2007-08-23 13:45 ` dberlin at dberlin dot org
2007-08-23 14:49 ` jakub at redhat dot com
2007-08-23 17:09 ` dberlin at dberlin dot org
2007-08-24 15:39 ` jakub at gcc dot gnu dot org
2007-08-24 15:42 ` dberlin at dberlin dot org [this message]
2007-08-24 16:17 ` jakub at gcc dot gnu dot org
2007-08-24 16:21 ` dberlin at dberlin dot org
2007-08-24 16:37 ` jakub at gcc dot gnu dot org
2007-09-05  1:09 ` mmitchel at gcc dot gnu dot org
2007-09-05  5:47 ` jakub at gcc dot gnu dot org
2007-09-11 17:21 ` jakub at gcc dot gnu dot org
2007-09-11 19:26 ` jakub at gcc dot gnu dot org
2007-09-11 19:52 ` jakub at gcc dot gnu dot org
2007-09-28  4:02 ` mmitchel at gcc dot gnu dot org
2007-10-15 18:30 ` jakub at gcc dot gnu dot org
2007-10-15 18:52 ` [Bug tree-optimization/33136] [4.1/4.2 " jakub at gcc dot gnu dot org
2008-07-04 22:16 ` [Bug tree-optimization/33136] [4.2 " jsm28 at gcc dot gnu dot org
2009-03-30 22:17 ` jsm28 at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070824154247.3555.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).