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: Tue, 27 Jan 2015 07:56:00 -0000 [thread overview] Message-ID: <bug-62173-4-Fh8SAAQ7F8@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 #27 from amker at gcc dot gnu.org --- (In reply to Jiong Wang from comment #24) > (In reply to amker from comment #23) > > partially agree. > > at least for the single use case given by Seb, I think tree ivopt should do > it. (I verified clang do ivopt correctly for the case) LLVM generates correct code, but I am not sure it's because of ivopt. The dump after ivopt for llvm is like below: ; Function Attrs: nounwind define void @bar(i32 %d) #0 { entry: %A = alloca [10 x i8], align 1 %cmp2 = icmp sgt i32 %d, 0 br i1 %cmp2, label %while.body.lr.ph, label %while.end while.body.lr.ph: ; preds = %entry %0 = sext i32 %d to i64 br label %while.body while.body: ; preds = %while.body.lr.ph, %while.body %indvars.iv = phi i64 [ %0, %while.body.lr.ph ], [ %indvars.iv.next, %while.body ] %indvars.iv.next = add nsw i64 %indvars.iv, -1 %scevgep = getelementptr i8* %A4, i64 %indvars.iv %1 = load i8* %scevgep, align 1, !tbaa !1 tail call void @foo(i8 %1) #2 %2 = add i64 %indvars.iv.next, 1 %cmp = icmp sgt i64 %2, 1 br i1 %cmp, label %while.body, label %while.end.loopexit The induction variable chosen is the original biv (d) actually, just like GCC. So even if we fix the idx_find_step issue, GCC's ivopt still can generate below codes: Loop-preheader ... Loop-body: iv = phi<d, -1> tmp = (POINTER_TYPE)&A; foo(MEM[base:tmp, index:iv]); Without proper RTL optimization, very likely the issue in calculation of base address of A still exists. > > for the rtl re-associate, it's a little bit painful from my experiment > experiences. as it's not always good to reassociate virtual_frame + offset, > we can only benefit if it's in loop, because the re-associate will increase > register pressure, there will be situations that more callee-saved regs > used, and finally we run into unncessary push/pop in pro/epilogue... and I > haven't found a good place where we can safely re-use existed rtl info and > do the rtl re-association as I am afraid rebuild those rtl info will cause > compile time penalty.
next prev parent reply other threads:[~2015-01-27 7:56 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 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 [this message] 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-Fh8SAAQ7F8@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).