From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85711 invoked by alias); 17 Dec 2015 23:41:50 -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 85693 invoked by uid 89); 17 Dec 2015 23:41:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=2-3, hmmm, latch, Hx-languages-length:2340 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; Thu, 17 Dec 2015 23:41:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 06743935D7; Thu, 17 Dec 2015 23:41:47 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-83.phx2.redhat.com [10.3.113.83]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBHNfkds023703; Thu, 17 Dec 2015 18:41:46 -0500 Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation To: Richard Biener References: <37378DC5BCD0EE48BA4B082E0B55DFAA41F3F56C@XAP-PVEXMBX02.xlnx.xilinx.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4295155D@XAP-PVEXMBX02.xlnx.xilinx.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4295ADCB@XAP-PVEXMBX02.xlnx.xilinx.com> <55D4F921.2020708@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4297704C@XAP-PVEXMBX02.xlnx.xilinx.com> <5643A732.4040707@redhat.com> <5644C6CC.90203@redhat.com> <5644DB59.9040809@redhat.com> <56450B62.4090404@redhat.com> <56460F19.5010009@redhat.com> <0B62FFB6-DF7A-4080-A655-3E51070E1DEE@gmail.com> <564646AA.5030300@redhat.com> <564673DA.3020403@redhat.com> <5669DBCD.1060507@redhat.com> Cc: Ajit Kumar Agarwal , GCC Patches , Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala From: Jeff Law Message-ID: <5673483A.7000505@redhat.com> Date: Thu, 17 Dec 2015 23:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01837.txt.bz2 On 12/11/2015 03:05 AM, Richard Biener wrote: > On Thu, Dec 10, 2015 at 9:08 PM, Jeff Law wrote: >> On 12/03/2015 07:38 AM, Richard Biener wrote: >>> >>> This pass is now enabled by default with -Os but has no limits on the >>> amount of >>> stmts it copies. >> >> The more statements it copies, the more likely it is that the path spitting >> will turn out to be useful! It's counter-intuitive. > > Well, it's still not appropriate for -Os (nor -O2 I think). -ftracer is enabled > with -fprofile-use (but it is also properly driven to only trace hot paths) > and otherwise not by default at any optimization level. I've just committed a patch to limit to loops we're optimizing for speed and moved the transformation from -O2 to -O3. I put in some instrumentation to see when this was triggering and, as expected the vast majority of triggers are with very small blocks, 2-3 statements. But those are probably the least interesting. There's limited instances where it triggers on large blocks (say > 10 statements). But those were with GCC sources. I'm going to pull out SPEC and do some instrumented builds with that, obviously focusing on those benchmarks where Ajit saw improvements. >> Hmmm, the updated code keeps the single latch property, but I'm pretty sure >> it won't keep a single exit policy. >> >> To keep a single exit policy would require keeping an additional block >> around. Each of the split paths would unconditionally transfer to this new >> block. The new block would then either transfer to the latch block or out >> of the loop. > > Don't see how this would work for the CFG pattern it operates on unless you > duplicate the exit condition into that new block creating an even more > obfuscated CFG. Upon further reflection, I don't think this is important as the pass runs after the tree loop optimizers. > > Note that both passes are placed quite late and thus won't see much > of the GIMPLE optimizations (DOM mainly). I wonder why they were > not placed adjacent to each other. I'm going to move them to be adjacent. If for no other reason than it'll make comparisons easier without having to worry about any passes between them. I suspect that'll drop in tonight after I get the kids to sleep :-) Jeff