From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13963 invoked by alias); 11 Apr 2012 22:48:36 -0000 Received: (qmail 13954 invoked by uid 22791); 11 Apr 2012 22:48:35 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_QD 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; Wed, 11 Apr 2012 22:48:22 +0000 From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/52898] SH Target: Inefficient DImode comparisons Date: Wed, 11 Apr 2012 22:48: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-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo 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 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-04/txt/msg00773.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898 --- Comment #1 from Oleg Endo 2012-04-11 22:48:18 UTC --- Created attachment 27138 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27138 Examples In addition to the original case, I've noticed that there are more weird things happening with DImode comparisons in general. The attached test cases do not cover all the possible combinations, but basically the -mcbranchdi and -mcmpeqdi options in combination with -O2 and -Os seem not to behave as originally intended. With -O2 the cmpeqdi_t pattern is never used no matter which options are specified. I think it is the split below the cmpeqdi_t insn in sh.md, that does this. The code of the cmpeqdi_t insn seems already quite optimal, except that the first cmp / tst insn should be emitted separately to get potentially better scheduling. Moreover, there is an unnamed tstdi_t pattern which never gets used by combine. What happens there, is that the and:DI is split by the middle-end into 2x and:SI at a very early stage. I think this is because there is no and:DI insn defined.