From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26218 invoked by alias); 30 Oct 2015 13:11:43 -0000 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 Received: (qmail 26205 invoked by uid 89); 30 Oct 2015 13:11:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Oct 2015 13:11:41 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-20-VPWzIo7URj2mfG6W56pNsQ-1; Fri, 30 Oct 2015 13:11:36 +0000 Received: from localhost ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2015 13:11:35 +0000 From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,GCC Patches , richard.sandiford@arm.com Cc: GCC Patches Subject: Re: Try to update dominance info in tree-call-cdce.c References: <87a8r0wqoe.fsf@e105548-lin.cambridge.arm.com> <871tccwo2g.fsf@e105548-lin.cambridge.arm.com> Date: Fri, 30 Oct 2015 13:11:00 -0000 In-Reply-To: (Richard Biener's message of "Fri, 30 Oct 2015 13:36:54 +0100") Message-ID: <87si4sv6uw.fsf@e105548-lin.cambridge.arm.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-MC-Unique: VPWzIo7URj2mfG6W56pNsQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-10/txt/msg03391.txt.bz2 Richard Biener writes: > On Fri, Oct 30, 2015 at 1:14 PM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Fri, Oct 30, 2015 at 12:18 PM, Richard Sandiford >>> wrote: >>>> The pass would free the dominance info after making a change, but it >>>> should be pretty easy to keep the information up-to-date when the call >>>> has no EH edges. In a way the main hurdle was split_block, which seem= ed >>>> to assume that the new block would postdominate the old one, and that >>>> all blocks immediately dominated by the old block are now immediately >>>> dominated by the new one. >>>> >>>> Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu. >>>> OK to install? >>> >>> Hmm, I don't understand why split_block needs to be touched. The >>> operation itself correctly updates dominator info. It is up to the >>> pass to fix things up if it does further CFG modifications that make >>> the new block no longer post-dominate the old one. >>> >>> So why do you need the split_block change? >> >> The updates we'd need here would be: >> >> redirect_immediate_dominators (CDI_DOMINATORS, call, guard_bb); >> >> which undoes the earlier: >> >> redirect_immediate_dominators (CDI_DOMINATORS, guard_bb, call); >> >> that split_block did. It just seemed wasteful to call >> redirect_immediate_dominators twice to get a no-op. >> >> In other words, there are going to be callers to split_block that >> know the second block isn't going to postdominate the first and >> where the calling; >> >> redirect_immediate_dominators (CDI_DOMINATORS, first_block, >> second_block); >> >> is taking us further from where we want to be. > > That's true. In an ideal world we'd have a CFG hook creating a > (half) diamond directly. > > I wonder how other passes work around this issue? I suppose > they are splitting the block to form the conditonal block and the > joiner? If you have those and then only split the fallthru edge > between them the redundant work done is minimal. Yeah, but that then makes the code more complicated because you still need to split the call block from the guard block rather than the joiner in the EH case. It also means that you need to do more set_immediate_dominators (the call is not the immediate dominator of the join block), whereas with the current code that falls out naturally. Is the split_block change really so bad? Thanks, Richard