From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18019 invoked by alias); 6 Feb 2015 18:36:56 -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 17958 invoked by uid 48); 6 Feb 2015 18:36:53 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/39723] [4.8/4.9/5 Regression][cond-optab] worse code with long long shifts on v850 Date: Fri, 06 Feb 2015 18:36: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: 4.5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: vmakarov at redhat dot com X-Bugzilla-Target-Milestone: 4.8.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to 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-02/txt/msg00616.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com Assignee|unassigned at gcc dot gnu.org |vmakarov at redhat dot com --- Comment #8 from Jeffrey A. Law --- Vlad, this looks like a register allocation issue to me. Using the current trunk configured for v850-elf, compiling the testcase from c#0 with -O2 and comparing it to the pre-cond-optab merge, I see that we're not coalescing some of the allocnos as aggressively as perhaps we should. Let's start with a13 and a17 and work backwards from their hard register assignments: Popping a13(r46,l0) -- assign reg 12 Popping a17(r53,l0) -- assign reg 10 These registers are related by a "copy" if we look up a bit in the .ira dump: Forming thread by copy 0:a13r46-a17r53 (freq=125): Result (freq=7000): a13r46(5000) a17r53(2000) cp0:a13(r46)<->a17(r53)@125:shuffle Looking at the conflicts: ;; a13(r46,l0) conflicts: a1(r68,l0) a0(r69,l0) a2(r70,l0) a4(r42,l0) a5(r67,l0) a6(r66,l0) a14(r62,l0) a15(r61,l0) a16(r60,l0) ;; total conflict hard regs: ;; conflict hard regs: ;; a17(r53,l0) conflicts: a2(r70,l0) a4(r42,l0) a5(r67,l0) a6(r66,l0) ;; total conflict hard regs: ;; conflict hard regs: Failing to allocate these two registers to r10 results in a 3-operand add (2 bytes longer) and an unnecessary move (2 bytes). Fixing that would appear to eliminate the regression. For reference, the add insn is defined as: (define_insn "addsi3" [(set (match_operand:SI 0 "register_operand" "=r,r,r") (plus:SI (match_operand:SI 1 "register_operand" "%0,r,r") (match_operand:SI 2 "nonmemory_operand" "rJ,K,U"))) (clobber (reg:CC CC_REGNUM))] Alternative 0 is preferred whenever possible as it allows us to generate the shorter add instruction. I'd appreciate if you could investigate when you have the opportunity.