From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2153 invoked by alias); 12 Aug 2016 11:27:25 -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 2143 invoked by uid 89); 12 Aug 2016 11:27:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=fre, FRE, NEXT_PASS, next_pass X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 12 Aug 2016 11:27:23 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 1E4145445AF; Fri, 12 Aug 2016 13:27:21 +0200 (CEST) Date: Fri, 12 Aug 2016 11:27:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Jan Hubicka , gcc-patches@gcc.gnu.org, law@redhat.com Subject: Re: Early jump threading Message-ID: <20160812112720.GB68714@kam.mff.cuni.cz> References: <20160811140235.GA68714@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-08/txt/msg01013.txt.bz2 > > * passes.def (pass_early_thread_jumps): Schedule after forwprop. > > * tree-pass.h (make_pass_early_thread_jumps): Declare. > > * tree-ssa-threadbackward.c (fsm_find_thread_path, > > fsm_find_thread_path, profitable_jump_thread_path, > > fsm_find_control_statement_thread_paths, > > find_jump_threads_backwards): Add speed_p parameter. > > (pass_data_early_thread_jumps): New pass. > > (make_pass_early_thread_jumps): New function. > > > > Index: passes.def > > =================================================================== > > --- passes.def (revision 239218) > > +++ passes.def (working copy) > > @@ -84,6 +84,7 @@ along with GCC; see the file COPYING3. > > /* After CCP we rewrite no longer addressed locals into SSA > > form if possible. */ > > NEXT_PASS (pass_forwprop); > > + NEXT_PASS (pass_early_thread_jumps); > > What's the reason for this placement? I know Jeff argues that > as jump threading helps CSE we need to place it before CSE but > OTOH the FSM style threading relies on copies and redundancies > being optimized already and the above has only constants and copies > being propagated and forwprop left you with lots of dead code > (but it should also have copies and constants propagated but it > leaves PHIs alone, not propagating into them or removing degenerate > ones - sth to fix I guess). > > So I'd be interested to see threading statistics when you place > the threading pass after early FRE (or cd_dce). I guess early > FRE will already handle quite some of the simplistic "threading" > opportunities (it optimizes redundant checks) thus numbers may > even get worse here. > > That said - if you put it before early FRE then I'd put it > right after CCP, not after forwprop. I placed it just after forwprop becasue the pattern it handles: bb0: x = a COND b; if (x) goto ... else goto ... Will be transformed into: bb0: if (a COND b) goto ... else goto ... is probably going to help the simpistic analysis done by threadbackwards. I collected data with placement just before FRE and they were more or less identical. In general threading helps forward propagators becuase of code specialization it does. It does not like dead code (as it will get accounted and prevent duplication), degenerate PHIs (because it will do useless duplication - something to fix probably), and unpropagated temporaries (because fsm_find_control_statement_thread_paths does not look into them) Honza