From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48397 invoked by alias); 3 Jul 2015 03:06:57 -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 48334 invoked by uid 48); 3 Jul 2015 03:06:52 -0000 From: "amker at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn Date: Fri, 03 Jul 2015 03:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amker at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 6.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: 2015-07/txt/msg00211.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612 --- Comment #7 from amker at gcc dot gnu.org --- On powerpc32, the address candidate doesn't have the period precision to eliminate conditional iv. That's why bdn is generated. On powerpc64, the address candidate does have the period precision because the address type is of 64bit now. This reveals a missed-optimization in IVO. Currently tree level IVO doesn't know if the loop condition can be tranformed into low-overhead looping structure (using doloop). One exception is when the condition is a comparison of the candidate IV against ZERO (Even in this case, it doesn't know how much cost could be saved with doloop optimization, it just decrease the cost by a provisional const). As for this case, the loop condition is (w_3(D) > 511), which could be transformed to a comparison against ZERO in rtl level doloop optimization. Unfortunately, tree IVO knows nother about this. It's also difficult to check whether doloop is viable on GIMPLE, because there are many heuristics/fallouts in RTL transformation. I consider this as another inconsistency issue between tree IVO and rtl loop optimizers. Another example is RTL unroller messes up induction variables chosen by tree IVO. I think we could XFAIL this on powerpc64 for now. So what's your opinions? Thanks.