From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8411 invoked by alias); 10 Aug 2009 13:33:01 -0000 Received: (qmail 8400 invoked by uid 22791); 10 Aug 2009 13:33:01 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Aug 2009 13:32:50 +0000 Received: from cam-owa2.Emea.Arm.com (cam-owa2.emea.arm.com [10.1.105.18]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id n7ADWleI014369; Mon, 10 Aug 2009 14:32:47 +0100 (BST) Received: from [10.1.129.63] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 14:32:47 +0100 Subject: Re: ifcvt.c question. From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@arm.com To: Steven Bosscher Cc: gcc@gcc.gnu.org In-Reply-To: <571f6b510908100609p3211d20fl68698e6d9e406df8@mail.gmail.com> References: <1249902983.25908.44.camel@e200593-lin.cambridge.arm.com> <571f6b510908100609p3211d20fl68698e6d9e406df8@mail.gmail.com> Content-Type: text/plain Date: Mon, 10 Aug 2009 15:49:00 -0000 Message-Id: <1249911166.25908.84.camel@e200593-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00167.txt.bz2 On Mon, 2009-08-10 at 15:09 +0200, Steven Bosscher wrote: > On Mon, Aug 10, 2009 at 1:16 PM, Ramana > Radhakrishnan wrote: > > I wonder if the best way to fix this is to teach ifcvt.c to handle > > conditional returns. > > Yes. This is a bug in the middle-end. I can only guess why you are > the first to run into this (the ia64 return instruction is not > predicable?) but clearly the assert is bogus if the conditional branch > of the IF-block is actually a conditional return. I did try to see what happened with the ia64 port - The ia64 return insn is predicable but th port doesn't like to conditionalize the return for this particular case because current_frame_info.r[reg_save_b0] is 32 and not 0 as required. Not knowing enough about the ia64 backend I gave up at this point assuming that the port was DTRT. > > > Should I be fixing this inside ifcvt.c by handling > > conditional returns specially > > I think you should fix this inside ifcvt.c, but try to make the > handing of cond_return not too specially ;-) > > Alternatively, you could add a conditional call pattern and a > post-reload splitter to the ARM backend, and disallow the > EXIT_BLOCK_PTR as the JOIN-block in ifcvt.c. I have added a conditional call pattern by saying that the call pattern is predicable - I don't see what else you mean here. What do you want to split here ? The conditional return + call into a cond_call + return or conditional return into a conditional branch and return ... ( both of which are impossible really ! ) I don't see how one can fix this without special casing for a return here. Either fix it inside ifcvt.c as a special case or look for a way of doing this from the hooks that ifcvt appears to provide . Thanks, Ramana > > Ciao! > Steven