public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can Date: Mon, 26 Jan 2015 15:03:00 -0000 [thread overview] Message-ID: <bug-62173-4-Pefejtr4or@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-62173-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #23 from amker at gcc dot gnu.org --- Now I am less convinced that it's a tree ivopt issue. Tree optimizer has no knowledge about stack frame information for local array variables. With the original test, on 32-bits targets, tree ivopts happens to choose the IV of base address like below: <bb 16>: # ivtmp.11_82 = PHI <ivtmp.11_84(15), ivtmp.11_83(17)> _87 = (void *) ivtmp.11_82; _13 = MEM[base: _87, offset: 0B]; ivtmp.11_83 = ivtmp.11_82 - 1; _14 = (int) _13; foo (_14); if (ivtmp.11_83 != _88) goto <bb 17>; else goto <bb 3>; <bb 17>: goto <bb 16>; IMHO, we shouldn't depend on this. It's much clearer to consider the exactly multiple-use example in previous comment, but this time in loop context: void bar(int i) { char A[10]; char B[10]; char C[10]; int d = 0; while (i > 0) A[d++] = i--; while (d > 0) { foo(A[d]); foo(B[d]); foo(C[d]); d--; } } Tree ivopt has no knowledge that references of A/B/C in loop share common sub-expression. Most likely (as suggested by previous comments), GCC will generates below IR: <bb 15>: _93 = (sizetype) i_6(D); _94 = &A + _93; ivtmp.11_92 = (unsigned int) _94; _98 = (sizetype) i_6(D); _99 = _98 + 1; _100 = &B + _99; ivtmp.15_97 = (unsigned int) _100; _104 = (sizetype) i_6(D); _105 = _104 + 1; _106 = &C + _105; ivtmp.20_103 = (unsigned int) _106; _110 = (unsigned int) &A; <bb 16>: # ivtmp.11_90 = PHI <ivtmp.11_92(15), ivtmp.11_91(17)> # ivtmp.15_95 = PHI <ivtmp.15_97(15), ivtmp.15_96(17)> # ivtmp.20_101 = PHI <ivtmp.20_103(15), ivtmp.20_102(17)> _107 = (void *) ivtmp.11_90; _13 = MEM[base: _107, offset: 0B]; ivtmp.11_91 = ivtmp.11_90 - 1; _14 = (int) _13; foo (_14); ivtmp.15_96 = ivtmp.15_95 - 1; _108 = (void *) ivtmp.15_96; _16 = MEM[base: _108, offset: 0B]; _17 = (int) _16; foo (_17); ivtmp.20_102 = ivtmp.20_101 - 1; _109 = (void *) ivtmp.20_102; _19 = MEM[base: _109, offset: 0B]; _20 = (int) _19; foo (_20); if (ivtmp.11_91 != _110) goto <bb 17>; else goto <bb 3>; <bb 17>: goto <bb 16>; It not good at least on targets without auto-increment addressing modes. Even on ARM/AARCH64 with auto-increment addressing modes, it's not always practical because of bloated loop-setup, or register pressure issue caused by duplicated inducation variables. In this case, we should associate "virtual_frame + offset1" and hoist it out of loop, while in loop, we should choose only one inducation variable (the biv), then refer to A/B/C using offset addressing mode like below: <bb 15> base_1 = virtual_frame + off1 <bb 16>: # d_26 = PHI <init, d_13> base_2 = base_1 + d_26 d_13 = d_26 - 1; foo (MEM[base_2, off_A]) foo (MEM[base_2, off_B]) foo (MEM[base_2, off_C]) goto <bb 16> So maybe this is a RTL issue, we firstly should do reassociation like "virtual_frame + reg + offset" to "(virtual_frame + offset) + reg". As for missed CSE opportunities in address expressions, maybe it can be fixed by an additional strength reduction pass on RTL, just like gimple-strength-reduction pass. The rtl pass is necessary simply because the gimple one has no knowledge of stack frame information, just like tree IVOPT.
next prev parent reply other threads:[~2015-01-26 15:03 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-08-18 16:12 [Bug target/62173] New: [AArch64] Performance regression due to r213488 spop at gcc dot gnu.org 2014-08-18 16:39 ` [Bug target/62173] " pinskia at gcc dot gnu.org 2014-08-18 19:13 ` spop at gcc dot gnu.org 2014-08-19 1:37 ` amker at gcc dot gnu.org 2014-10-28 11:28 ` [Bug target/62173] [5.0 regression] " jiwang at gcc dot gnu.org 2014-11-14 9:37 ` jiwang at gcc dot gnu.org 2014-11-17 2:14 ` amker.cheng at gmail dot com 2014-11-24 12:15 ` jiwang at gcc dot gnu.org 2014-11-24 12:38 ` jiwang at gcc dot gnu.org 2014-11-24 13:06 ` rguenth at gcc dot gnu.org 2014-11-24 23:01 ` jiwang at gcc dot gnu.org 2014-11-26 10:54 ` [Bug target/62173] [5.0 regression] [AArch64] Can't ivopt array base address while ARM can jiwang at gcc dot gnu.org 2014-11-27 9:35 ` jiwang at gcc dot gnu.org 2014-11-27 12:00 ` [Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can rguenther at suse dot de 2014-11-27 12:16 ` rguenther at suse dot de 2014-11-27 13:34 ` jiwang at gcc dot gnu.org 2015-01-23 17:33 ` jiwang at gcc dot gnu.org 2015-01-26 10:30 ` rguenth at gcc dot gnu.org 2015-01-26 11:10 ` rguenth at gcc dot gnu.org 2015-01-26 13:48 ` ramana at gcc dot gnu.org 2015-01-26 14:19 ` amker at gcc dot gnu.org 2015-01-26 14:51 ` rguenther at suse dot de 2015-01-26 14:53 ` rguenther at suse dot de 2015-01-26 15:03 ` amker at gcc dot gnu.org [this message] 2015-01-26 15:38 ` jiwang at gcc dot gnu.org 2015-01-27 3:21 ` amker at gcc dot gnu.org 2015-01-27 7:56 ` amker at gcc dot gnu.org 2015-01-27 9:11 ` rguenther at suse dot de 2015-01-28 18:26 ` LpSolit at netscape dot net 2015-01-29 6:48 ` amker at gcc dot gnu.org 2015-01-30 6:42 ` amker at gcc dot gnu.org 2015-01-30 12:32 ` rguenth at gcc dot gnu.org 2015-02-05 7:27 ` amker at gcc dot gnu.org 2015-03-11 17:30 ` [Bug tree-optimization/62173] [5 Regression] " jiwang at gcc dot gnu.org 2015-03-11 17:46 ` jiwang at gcc dot gnu.org 2015-03-11 17:52 ` [Bug tree-optimization/62173] [5/6 " jakub at gcc dot gnu.org 2015-03-13 8:34 ` amker at gcc dot gnu.org 2015-06-02 3:34 ` amker at gcc dot gnu.org 2015-06-03 3:56 ` amker at gcc dot gnu.org 2015-07-22 11:44 ` jiwang 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-62173-4-Pefejtr4or@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).