From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20497 invoked by alias); 26 Nov 2014 10:54:02 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 20423 invoked by uid 48); 26 Nov 2014 10:53:59 -0000 From: "jiwang at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/62173] [5.0 regression] [AArch64] Can't ivopt array base address while ARM can Date: Wed, 26 Nov 2014 10:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jiwang at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: jiwang at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-11/txt/msg03090.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 Jiong Wang changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[5.0 regression] [AArch64] |[5.0 regression] [AArch64] |Performance regression due |Can't ivopt array base |to r213488 |address while ARM can --- Comment #11 from Jiong Wang --- (In reply to amker from comment #3) > I have seen potential improvement of bzip/gzip on arm 32. It relates to > addressing mode which affecting loop invariant hoisting in kernel loop of > these two benchmarks. I once had a patch but didn't follow up that. I > think it's worthy of methodical investigation, rather than case by case > changes. > > Thanks, > bin exactly. the fix in lra elimination only reduce one unnecessary add instructions add x1, x29, 48 add x0, x1, x0, sxtw ldrb w0, [x0, -16] transformed into add x0, 29, x0, sxtw ldrb w0, [x0, 32] Pinski'a case is fixed by this. But for Seb's case, still the base address calculation is not hoisted outside the loop which is critical. And If we re-associate ((virtual_fp + reg) + offset) into ((virtual_fp + offset) + reg), then the later RTL GCSE pre pass will identify virtual_fp + offset as loop invariant and do the hoisting. But the re-association is not always good when there are multi-use etc. While for ARM backend, although there is the lra elimination issue, there is no base address hoisting issue. From the tree dump, ARM and AArch64 do get difference result after ivopt pass. Will create a seperate bugzilla for lra elimination issue