From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72818 invoked by alias); 15 Dec 2015 23:50:08 -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 72743 invoked by uid 89); 15 Dec 2015 23:50:07 -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_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Tue, 15 Dec 2015 23:50:03 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id C804AA1707; Tue, 15 Dec 2015 23:50:01 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-83.phx2.redhat.com [10.3.113.83]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tBFNo1ZB016456; Tue, 15 Dec 2015 18:50:01 -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: <5670A728.8090500@redhat.com> Date: Tue, 15 Dec 2015 23:50: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/msg01539.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. Definitely not appropriate for -Os. But as I mentioned, I really want to look at the tracer code as it may totally subsume path splitting. > > 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. Agreed, I don't see any way to fix the multiple exit problem. Then again, this all runs after the tree loop optimizer, so I'm not sure how big of an issue it is in practice. >> It was only after I approved this code after twiddling it for Ajit that I >> came across Honza's tracer implementation, which may in fact be >> retargettable to these loops and do a better job. I haven't experimented >> with that. > > Well, I originally suggested to merge this with the tracer pass... I missed that, or it didn't sink into my brain. >> Again, the more statements it copies the more likely it is to be profitable. >> Think superblocks to expose CSE, DCE and the like. > > Ok, so similar to tracer (where I think the main benefit is actually increasing > scheduling opportunities for architectures where it matters). Right. They're both building superblocks, which has the effect of larger windows for scheduling, DCE, CSE, etc. > > 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. Ajit had it fairly early, but that didn't play well with if-conversion. I just pushed it past if-conversion and vectorization, but before the last DOM pass. That turns out to be where tracer lives too as you noted. >> >> I wouldn't lose any sleep if we disabled by default or removed, particularly >> if we can repurpose Honza's code. In fact, I might strongly support the >> former until we hear back from Ajit on performance data. > > See above for what we do with -ftracer. path-splitting should at _least_ > restrict itself to operate on optimize_loop_for_speed_p () loops. I think we need to decide if we want the code at all, particularly given the multiple-exit problem. The difficulty is I think Ajit posted some recent data that shows it's helping. So maybe the thing to do is ask Ajit to try the tracer independent of path splitting and take the obvious actions based on Ajit's data. > > It should also (even if counter-intuitive) limit the amount of stmt copying > it does - after all there is sth like an instruction cache size which exceeeding > for loops will never be a good idea (and even smaller special loop caches on > some archs). Yup. > > Note that a better heuristic than "at least more than one stmt" would be > to have at least one PHI in the merger block. Otherwise I don't see how > CSE opportunities could exist we don't see without the duplication. > And yes, more PHIs -> more possible CSE. I wouldn't say so for > the number of stmts. So please limit the number of stmt copies! > (after all we do limit the number of stmts we copy during jump threading!) Let's get some more data before we try to tune path splitting. In an ideal world, the tracer can handle this for us and we just remove path splitting completely. Jeff