From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6363 invoked by alias); 13 Oct 2011 22:55:36 -0000 Received: (qmail 6353 invoked by uid 22791); 13 Oct 2011 22:55:36 -0000 X-SWARE-Spam-Status: No, hits=-2.9 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; Thu, 13 Oct 2011 22:55:17 +0000 From: "oleg.endo@t-online.de" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction Date: Thu, 13 Oct 2011 22:55: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: enhancement X-Bugzilla-Who: oleg.endo@t-online.de 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: Attachment #24412 is obsolete 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: 2011-10/txt/msg01301.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 Oleg Endo changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #24412|0 |1 is obsolete| | --- Comment #11 from Oleg Endo 2011-10-13 22:54:54 UTC --- Created attachment 25491 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25491 Proposed patch including test case > > 3) only zero_extract special cases > > looks to be dominant. Yes. I've briefly looked through the test sources. A popular use case for bit test instructions seem to be single bit tests, which the patch is basically adding. > I see. I also expect that the experts have some idea for > this issue. Hm .. http://gcc.gnu.org/ml/gcc/2011-10/msg00189.html Eric pointed me to the i386 back-end. Unfortunately, what I found there is where I originally started... ;; Combine likes to form bit extractions for some tests. Humor it. I.e. it is also coded against the behavior of the combine pass with a bunch of pattern variations. I guess that's the way it's supposed to be done then :T > I don't think that it's too much. Those numbers can be easily > collected for CSiBE. If your patterns are named, you could > simply add "-dap -save-temps" to the compiler option which is > specified when ruining CSiBE's create-config and then get > the occurrences of testsi_6, for example, with something like > grep "testsi_6" `find . -name "*.s" -print` | wc -l > after running the CSiBE size test. Ah, right! With the attached latest patch applied to trunk rev 179778 the numbers for "-ml -m4-single -Os -mnomacsave -mpretend-cmove -mfused-madd -freg-struct-return" look something like that: tstsi_t: 1391 tsthi_t: 4 tstqi_t: 23 tstqi_t_zero: 667 tstsi_t_and_not: 598 tstsi_t_zero_extract_eq: 70 tstsi_t_zero_extract_xor: 923 Notice that the split contributes to the tstsi_t number. Also, the 3 patterns tstsi_t_zero_extract_xor tstsi_t_zero_extract_subreg_xor_little tstsi_t_zero_extract_subreg_xor_big are basically one and the same. On SH4A the subreg variants are required, because tstsi_t_zero_extract_xor will never match. I've also added a special case to sh_rtx_costs to detect at least the tstsi_t pattern. However, the other patterns are not really covered by that and the combine pass calculates the cost as a sum of all the operations of the pattern. I guess the selection of the test instruction could be stimulated a bit more by a more accurate costs calculation, but my feeling is that it won't do a lot. Cheers, Oleg