From patchwork Tue Sep 13 15:36:14 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 114508 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id DC925B71CC for ; Wed, 14 Sep 2011 01:36:47 +1000 (EST) Received: (qmail 13453 invoked by alias); 13 Sep 2011 15:36:44 -0000 Received: (qmail 13251 invoked by uid 22791); 13 Sep 2011 15:36:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Sep 2011 15:36:28 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R3V2B-0002kE-Aj from Bernd_Schmidt@mentor.com ; Tue, 13 Sep 2011 08:36:27 -0700 Received: from [127.0.0.1] ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2011 16:36:25 +0100 Message-ID: <4E6F786E.6080407@codesourcery.com> Date: Tue, 13 Sep 2011 17:36:14 +0200 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110905 Lightning/1.0b3pre Thunderbird/3.1.12 MIME-Version: 1.0 To: GCC Patches , richard.sandiford@linaro.org CC: Richard Henderson Subject: Re: Initial shrink-wrapping patch References: <4E5E7342.9050103@codesourcery.com> <4E6E9857.50600@t-online.de> <4E6F37D9.9000108@t-online.de> <4E6F4B90.2050408@codesourcery.com> In-Reply-To: Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On 09/13/11 15:05, Richard Sandiford wrote: > It just feels like checking for trap_if or turning off cross-jumping > are working around problems in the representation of shrink-wrapped > functions. There should be something in the IL to say that those > two blocks cannot be merged for CFI reasons. There is - JUMP_LABELs and such, and the simple_return vs return distinction. This works for essentially all the interesting cases. The problem here is that we don't have a jump as the last insn. So how about the solution in crossjumping as below? > Maybe two flags on > the basic block to say whether they start (resp. end) with the > "wrapped" version of the CFI? (Which unfortunately would need > to be checked explicitly.) I think that's overdesigning it, and it breaks as soon as something discards the bb info (reorg...) or puts a label in the middle of a prologue or epilogue. Keeping that up-to-date would be much more fragile than just manually dealing with the few cases where we can't tell what's going on. > OTOH, if another reviewer thinks that's unreasnable, I'll happily > defer to them. Cc'ing rth for a second opinion... Bernd * cfgcleanup.c (outgoing_edges_match): Nonjump edges to the EXIT_BLOCK_PTR match only if we did not perform shrink-wrapping. Index: gcc/cfgcleanup.c =================================================================== --- gcc/cfgcleanup.c (revision 178734) +++ gcc/cfgcleanup.c (working copy) @@ -1488,6 +1488,16 @@ outgoing_edges_match (int mode, basic_bl edge e1, e2; edge_iterator ei; + /* If we performed shrink-wrapping, edges to the EXIT_BLOCK_PTR can + only be distinguished for JUMP_INSNs. The two paths may differ in + whether they went through the prologue. Sibcalls are fine, we know + that we either didn't need or inserted an epilogue before them. */ + if (flag_shrink_wrap + && single_succ_p (bb1) && single_succ (bb1) == EXIT_BLOCK_PTR + && !JUMP_P (BB_END (bb1)) + && !(CALL_P (BB_END (bb1)) && SIBLING_CALL_P (BB_END (bb1)))) + return false; + /* If BB1 has only one successor, we may be looking at either an unconditional jump, or a fake edge to exit. */ if (single_succ_p (bb1)