From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5974 invoked by alias); 21 May 2011 20:57:11 -0000 Received: (qmail 5963 invoked by uid 22791); 21 May 2011 20:57:10 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Sat, 21 May 2011 20:56:56 +0000 From: "torvalds@linux-foundation.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: torvalds@linux-foundation.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sat, 21 May 2011 21:33:00 -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 X-SW-Source: 2011-05/txt/msg01884.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #3 from Linus Torvalds 2011-05-21 20:42:26 UTC --- Hmm. Looking at that code generation, it strikes me that even with the odd load store situation, why do we have that "test" instruction? c: 8b 10 mov (%eax),%edx e: 83 ea 01 sub $0x1,%edx 11: 85 d2 test %edx,%edx 13: 89 10 mov %edx,(%eax) 15: 74 09 je 20 iow, regardless of any complexities of the store, that "sub + test" is just odd. Gcc knows to simplify that particular sequence in other situations, why doesn't it simplify it here? IOW, I can make gcc generate code like c: 83 e8 01 sub $0x1,%eax f: 75 07 jne 18 with no real problem when it's in registers. No "test" instruction after the sub. Why does that store matter so much? It looks like the combine is bring driven by the conditional branch, and then when the previous instruction from the conditional branch is that store, everything kind of goes to hell. Would it be possible to have a peephole for the "arithmetic/logical + compare-with-zero" case (causing us to just drop the compare), and then have a separate peephole optimization that triggers the "load + op + store with dead reg" and turns that into a "op to mem" case? The MD files do make me confused, so maybe there is some fundamental limitation to the peephole patterns that makes this impossible?