From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14987 invoked by alias); 27 Jun 2011 05:15:24 -0000 Received: (qmail 14975 invoked by uid 22791); 27 Jun 2011 05:15:23 -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; Mon, 27 Jun 2011 05:15:09 +0000 From: "kkojima at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: kkojima at gcc dot gnu.org 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: 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: Mon, 27 Jun 2011 05:15: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-06/txt/msg02274.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #6 from Kazumoto Kojima 2011-06-27 05:14:36 UTC --- (In reply to comment #5) > Anyway, why not just add all the currently known-to-work cases? What are your > concerns regarding that? I can imagine that it is a maintenance burden to keep > all those definitions and special cases in the MD up-to-date (bit rot etc). Do > you have anything other than that in mind? Yep, maintenance burden but I don't mean ack/nak for anything. If it's enough fruitful, we should take that route. When it gives 5% improvement in the usual working set like as CSiBE, hundreds lines would be OK, but if it's ~0.5% or less, it doesn't look worth to add many patterns for that. > Isn't there a way to tell the combine pass not to do so, but instead first look > deeper at what is in the MD? I don't know how to do it cleanly. > I guess this might generate wrong code for e.g. "if (x & -2)". When x has any > bits[31:1] set this must return true. The code after the peephole optimization > will look only at the lower 8 bits and would possibly return false for x = > 0xFF000000, which is wrong. So it should be satisfies_constraint_K08 only, > shouldn't it? You are right. That peephole was simply 'something like this'.