From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23850 invoked by alias); 8 Jul 2011 08:27:54 -0000 Received: (qmail 23840 invoked by uid 22791); 8 Jul 2011 08:27:52 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (94.185.240.25) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Fri, 08 Jul 2011 08:27:38 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 08 Jul 2011 09:27:34 +0100 Received: from [10.1.67.34] ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Jul 2011 09:27:31 +0100 Message-ID: <4E16BF73.5030107@arm.com> Date: Fri, 08 Jul 2011 08:30:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Richard Earnshaw , Bernd Schmidt , GCC Patches , "richard.sandiford@linaro.org" , rdsandiford@googlemail.com Subject: Re: [PATCH 4/6] Shrink-wrapping References: <4D8A0703.9090306@codesourcery.com> <4D8A095C.8050809@codesourcery.com> <4E15D6CD.5020600@arm.com> <87vcvdetw8.fsf@firetop.home> In-Reply-To: <87vcvdetw8.fsf@firetop.home> X-MC-Unique: 111070809273401301 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2011-07/txt/msg00589.txt.bz2 On 07/07/11 21:08, Richard Sandiford wrote: > Richard Earnshaw writes: >> On 07/07/11 15:34, Richard Sandiford wrote: >>> It seems a shame to have both (return) and (simple_return). You said >>> that we need the distinction in order to cope with targets like ARM, >>> whose (return) instruction actually performs some of the epilogue too. >>> It feels like the load of the saved registers should really be expressed >>> in rtl, in parallel with the return. I realise that'd prevent >>> conditional returns though. Maybe there's no elegant way out... >> >> You'd still need to deal with distinct returns for shrink-wrapped code >> when the full (return) expands to >> >> ldm sp, {regs..., pc} >> >> The shrink wrapped version would always be >> bx lr >=20 > Sure, I understand that returns does more than return on ARM. > What I meant was: we'd normally want that other stuff to be > expressed in rtl alongside the (return) rtx. E.g. something like: >=20 > (parallel > [(return) > (set (reg r4) (mem (plus (reg sp) (const_int ...)))) > (set (reg r5) (mem (plus (reg sp) (const_int ...)))) > (set (reg sp) (plus (reg sp) (const_int ...)))]) >=20 > And what I meant was: the reason we can't do that is that it would make > conditional execution harder. But the downside is that (return) and > (simple_return) will appear to do the same thing to register r4 > (i.e. nothing). I.e. we are to some extent going to be lying to > the rtl optimisers. > Hmm, yes, that would certainly help in terms of ensuring the compiler knew the liveness correctly. But as you say, that doesn't match a simple-jump and that could lead to other problems. R.