From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9011 invoked by alias); 27 Jun 2008 13:56:55 -0000 Received: (qmail 9000 invoked by uid 22791); 27 Jun 2008 13:56:54 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate8.de.ibm.com (HELO mtagate8.de.ibm.com) (195.212.29.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jun 2008 13:56:31 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.13.8/8.13.8) with ESMTP id m5RDtsmC227052 for ; Fri, 27 Jun 2008 13:55:54 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5RDtsI93477558 for ; Fri, 27 Jun 2008 15:55:54 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5RDtsIb026370 for ; Fri, 27 Jun 2008 15:55:54 +0200 Received: from lc4eb0107015440.ibm.com (dyn-9-152-216-65.boeblingen.de.ibm.com [9.152.216.65]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m5RDtrU4026345; Fri, 27 Jun 2008 15:55:53 +0200 Received: by lc4eb0107015440.ibm.com (sSMTP sendmail emulation); Fri, 27 Jun 2008 15:55:54 +0200 From: "Andreas Krebbel" Date: Fri, 27 Jun 2008 13:57:00 -0000 To: Gunnar Von Boehn Cc: schwab@suse.de, gcc-patches@gcc.gnu.org Subject: Re: Fix for GCC Bugzilla Bug 36133 Message-ID: <20080627135554.GA19684@homer.boeblingen.de.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg01744.txt.bz2 Hi Gunnar, Hi Andreas, although your thoughts are correct if you think assembly-wise. I think GCC could indeed create lsr;tst;jhi combinations. As you say the branch would then never be taken due to the carry flag but it is still correct code which would break if the tst gets optimized away. Maybe Andreas was thinking about an example like this: int foo (unsigned int a, unsigned int b, unsigned int c) { unsigned int t = a << b; if (t > c) return 31; return 42; } int bar (unsigned int a, unsigned int b) { return foo (a, b, 0); } The code for foo would contain something like this: ... lsl.l %d1,%d0 cmp.l 16(%fp),%d0 jhi .L2 But after inlining GCC is able to see that the second operand is always 0 and replaces the cmp instruction with the simpler tst. Although that would render the carry flag check in jhi pointless it is correct to do so. The cmp instruction would in that case never have set the carry flag anyway - very much the same way the tst instruction never does. Unfortunately the example is not really a good one since the inlining is already takes place at tree level so that the RTL expansion already picks the NE comparison operator for bar which result in a jne instruction. But I think you can imagine that a more intricate example could make GCC to recognize the possibility to replace cmp with tst later in the RTL optimization which might lead to the lsl; tst; jhi combination. I've pointed you to the solution you have posted since that's the way we do it on S/390 - sorry for sending you in a somewhat wrong direction. It would be correct for 68k if the current semantics of CC could be taken into account when matching instructions. That's why several back ends do not use cc0 for condition code handling. By using a normal register as CC it is possible to do the matching over the attached mode. The mode of CC then makes sure that the compare and the conditional branch fit together. Using cc0 it is only possible to state that the current CC is invalid to use what is done for the shift instructions as Andreas pointed out. Making the m68k back end to not use cc0 anymore would require a major rework. But I think it would be worth the effort since there are probably a lot of situation were you could get rid of superfluous tests. Andreas what do you think? Another solution (although quite an ugly one) would be to do a check for redundant tests in the machine dependent reorg pass but that's certainly not preferable. Bye, -Andreas-