public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment Date: Mon, 16 Jan 2012 15:43:00 -0000 [thread overview] Message-ID: <bug-50444-4-nxezw1xtpx@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-50444-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50444 --- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-16 15:25:06 UTC --- Testcase w/o includes that fails with 4.6 and 4.7: typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__)); typedef int __v4si __attribute__ ((__vector_size__ (16))); typedef long long __v2di __attribute__ ((__vector_size__ (16))); typedef unsigned int uint32_t; typedef struct { uint32_t v[4]; } a4x32; a4x32* incr(a4x32* x) { x->v[0] += 1; return x; } typedef struct { __m128i m; } a1xm128i; static inline a1xm128i ssefunc( a1xm128i in, a1xm128i k) { a1xm128i ret; ret.m = (__m128i)__builtin_ia32_pxor128 ((__v2di)in.m, (__v2di)k.m); return ret; } static a4x32 caster( a4x32 c4x32, a1xm128i k) { a1xm128i c1x128; if( sizeof(c4x32) != sizeof(c1x128) ) __builtin_abort(); __builtin_memcpy(&c1x128, &c4x32, sizeof(c1x128)); c1x128 = ssefunc(c1x128, k); __builtin_memcpy(&c4x32, &c1x128, sizeof(c4x32)); return c4x32; } typedef struct { a1xm128i key; a4x32 c; __SIZE_TYPE__ elem; a4x32 v; } Engine; void ctor(Engine *e) { e->elem = 0; e->key.m = (__m128i)(__v4si){ 0, 0, 0, 0 }; e->c.v[0] = 0; e->c.v[1] = 0; e->c.v[2] = 0; e->c.v[3] = 0; } uint32_t method( Engine *e) { if( e->elem == 0 ) { e->v = caster(*incr(&e->c), e->key); e->elem = 4; } return e->v.v[--e->elem]; } int main() { Engine e4; ctor(&e4); Engine e5; ctor(&e5); if(method(&e4)!=method(&e5)) __builtin_abort (); return 0; } and the problematic SRA is indeed happening during ESRA in caster () which looks like (before SRA): <bb 2>: MEM[(char * {ref-all})&c1x128] = MEM[(char * {ref-all})&c4x32]; in = c1x128; k = k; D.1785_7 = k.m; D.1784_8 = in.m; D.1783_9 = __builtin_ia32_pxor128 (D.1784_8, D.1785_7); D.1782.m = D.1783_9; D.1780 = D.1782; c1x128 = D.1780; MEM[(char * {ref-all})&c4x32] = MEM[(char * {ref-all})&c1x128]; D.1760 = c4x32; c1x128 ={v} {CLOBBER}; return D.1760; and after SRA: <bb 2>: c4x32$m_4 = MEM[(struct *)&c4x32].m; c1x128$m_14 = c4x32$m_4; in$m_13 = c1x128$m_14; k$m_12 = MEM[(struct *)&k].m; D.1785_7 = k$m_12; D.1784_8 = in$m_13; D.1783_9 = __builtin_ia32_pxor128 (D.1784_8, D.1785_7); SR.6_11 = D.1783_9; SR.7_10 = SR.6_11; c1x128$m_2 = SR.7_10; c4x32$m_15 = c1x128$m_2; MEM[(struct *)&D.1760].m = c4x32$m_15; c1x128$m_16 = { 0, 0 }; return D.1760; notice that D.1760 is of type a4x32 and thus has the alignment of an integer. But SRA constructs in-place the object of type c1x128. SRA analysis should have seen the alignment breaking copy MEM[(char * {ref-all})&c4x32] = MEM[(char * {ref-all})&c1x128]; which uses a properly aligned type for the store. Similarly the prevailing store D.1760 = c4x32; has the alignment of D.1760. D.1760 already has a bogus type in lacc->type. We can easily avoid translating across aggregate copies that would transfer bogusly aligned types to an access via Index: tree-sra.c =================================================================== --- tree-sra.c (revision 183205) +++ tree-sra.c (working copy) @@ -2290,7 +2290,9 @@ propagate_subaccesses_across_link (struc if (is_gimple_reg_type (racc->type)) { - if (!lacc->first_child && !racc->first_child) + if (!lacc->first_child && !racc->first_child + && (get_object_alignment (lacc->expr) + >= get_object_alignment (racc->expr))) { tree t = lacc->base; or make sure to transfer the alignment to a constructed bare(!) MEM_REF from lacc->expr before overwriting that (assuming it retains the original form up until here).
next prev parent reply other threads:[~2012-01-16 15:25 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-09-17 17:12 [Bug c/50444] New: unaligned movdqa instruction after inlining john.salmon at deshaw dot com 2011-09-25 15:45 ` [Bug c/50444] " john.salmon at deshaw dot com 2011-09-25 18:06 ` rguenth at gcc dot gnu.org 2011-09-26 17:46 ` hjl.tools at gmail dot com 2011-09-26 17:56 ` [Bug c/50444] -ftree-isa ignores alignment hjl.tools at gmail dot com 2011-09-26 20:06 ` hjl.tools at gmail dot com 2011-09-27 8:59 ` rguenther at suse dot de 2011-10-24 7:55 ` [Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra " rguenth at gcc dot gnu.org 2011-10-26 17:38 ` jakub at gcc dot gnu.org 2011-10-27 10:19 ` rguenth at gcc dot gnu.org 2011-12-16 19:59 ` jamborm at gcc dot gnu.org 2011-12-17 15:41 ` ebotcazou at gcc dot gnu.org 2012-01-12 13:47 ` jamborm at gcc dot gnu.org 2012-01-16 15:43 ` rguenth at gcc dot gnu.org [this message] 2012-01-16 15:58 ` rguenth at gcc dot gnu.org 2012-01-18 11:57 ` jamborm at gcc dot gnu.org 2012-01-20 14:27 ` rguenth at gcc dot gnu.org 2012-01-20 15:54 ` rguenth at gcc dot gnu.org 2012-01-27 15:12 ` rguenth at gcc dot gnu.org 2012-01-27 15:23 ` rguenth at gcc dot gnu.org 2012-01-27 15:29 ` [Bug tree-optimization/50444] [4.6 " rguenth at gcc dot gnu.org 2012-03-01 15:21 ` jakub at gcc dot gnu.org 2013-04-12 16:17 ` jakub at gcc dot gnu.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=bug-50444-4-nxezw1xtpx@http.gcc.gnu.org/bugzilla/ \ --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).