From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26801 invoked by alias); 13 Feb 2012 16:55:44 -0000 Received: (qmail 26790 invoked by uid 22791); 13 Feb 2012 16:55:43 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,SUBJ_OBFU_PUNCT_FEW X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 13 Feb 2012 16:55:30 +0000 From: "Paulo.Matos at csr dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/52235] New: rtlanal: commutative_operand_precedence should prioritize regs Date: Mon, 13 Feb 2012 16:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Paulo.Matos at csr dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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 X-SW-Source: 2012-02/txt/msg01330.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52235 Bug #: 52235 Summary: rtlanal: commutative_operand_precedence should prioritize regs Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: Paulo.Matos@csr.com I noticed the combine receives insns of the form: (set (reg ...) (ior (mem (reg ...)) (reg ...))) (in my specific case the reg inside mem was an argument pointer that later would be eliminated in terms of a function pointer. After an initial discussion in the mailing list: http://www.mail-archive.com/gcc@gcc.gnu.org/msg62132.html Richard pointed me to commutative_operand_precedence. Both him and I expected to see the register come first. Having the register come first is more intuitive and under my backend it performs much better. The whole reason to look into this stemmed from the fact that commutative operations like ior were not being correctly combined since the backend rule looked like: (define_insn "iorqi3" [(set (match_operand:QI 0 "register_operand" "=c") (ior:QI (match_operand:QI 1 "register_operand" "%0") (match_operand:QI 2 "general_operand" "cwmi"))) (clobber (reg:CC RCC))] "" "or\\t%0,%f2") Makes sense for operand1 to be a register_operand because it will be forced to be the same as operand0. However, if we can't assume registers come first a lot of rule duplication has to occur in order to achieve the same effect. I would guess in this case I would need to have instead of the above: (define_insn "iorqi3" [(set (match_operand:QI 0 "register_operand" "=c") (ior:QI (match_operand:QI 1 "register_operand" "0") (match_operand:QI 2 "general_operand" "cwmi"))) (clobber (reg:CC RCC))] "" "or\\t%0,%f2") (define_insn "iorqi3" [(set (match_operand:QI 0 "register_operand" "=c") (ior:QI (match_operand:QI 1 "general_operand" "cwmi") (match_operand:QI 2 "register_operand" "0"))) (clobber (reg:CC RCC))] "" "or\\t%0,%f1") The simple fix of making registers have priority over everything else works like a charm. Patch follows.