From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91270 invoked by alias); 17 Aug 2015 17:48:39 -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 91257 invoked by uid 89); 17 Aug 2015 17:48:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 17 Aug 2015 17:48:37 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8D00F8E22D; Mon, 17 Aug 2015 17:48:36 +0000 (UTC) Received: from redhat.com (ovpn-204-54.brq.redhat.com [10.40.204.54]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7HHmWAV017045 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 17 Aug 2015 13:48:35 -0400 Date: Mon, 17 Aug 2015 18:01:00 -0000 From: Marek Polacek To: Jeff Law Cc: Richard Biener , GCC Patches Subject: Re: [PATCH] Fix middle-end/67133, part 1 Message-ID: <20150817174831.GH2093@redhat.com> References: <20150814112006.GR3335@redhat.com> <20150814132945.GS3335@redhat.com> <55CE002E.6000108@redhat.com> <20150814153224.GU3335@redhat.com> <55CE0A5A.4070802@redhat.com> <20150814195836.GB2093@redhat.com> <55CE5054.5080400@redhat.com> <20150814204649.GC2093@redhat.com> <55D21A8D.50004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55D21A8D.50004@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-08/txt/msg00918.txt.bz2 On Mon, Aug 17, 2015 at 11:31:57AM -0600, Jeff Law wrote: > The funny thing here is we remove the statements after the trap to avoid > this exact situation! > > I think the problem with schemes that either change the order of block > processing, or which ignore some blocks are going to run into issues. By > walking blocks and statements in a backwards order, we address 99% of the > problems, including uses in PHIs in a direct successor block. > > What's not handled is a use in a PHI at the frontier of a subgraph that > becomes unreachable. We'd have to do the usual unreachable block analysis > to catch and handle those properly. > > I don't particularly like that idea.... > > But in walking through all that, I think I've stumbled on a simpler > solution. Specifically do as a little as possible and let the standard > mechanisms clean things up :-) > > 1. Delete the code that removes instructions after the trap. > > 2. Split the block immediately after the trap and remove the edge > from the original block (with the trap) to the new block. > > > THen let the standard mechanisms handle things when that pass is complete. > > By setting cfg_altered, we'll get unreachable code removal which will > capture most of the intended effect. DCE fires a couple more passes down in > the pipeline to pick up the remaining tidbits. Ok, thanks. > Do you want to try and tackle this? Sure. I should have a patch tomorrow :-). Marek