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
next prev 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: linkBe 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).