From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23895 invoked by alias); 16 Dec 2015 09:57:17 -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 23886 invoked by uid 89); 16 Dec 2015 09:57:16 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qk0-f178.google.com Received: from mail-qk0-f178.google.com (HELO mail-qk0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 16 Dec 2015 09:57:15 +0000 Received: by mail-qk0-f178.google.com with SMTP id t125so55463539qkh.3 for ; Wed, 16 Dec 2015 01:57:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.50.199 with SMTP id y190mr1116854ywy.147.1450259832943; Wed, 16 Dec 2015 01:57:12 -0800 (PST) Received: by 10.37.202.82 with HTTP; Wed, 16 Dec 2015 01:57:12 -0800 (PST) In-Reply-To: <37378DC5BCD0EE48BA4B082E0B55DFAA429D65A4@XAP-PVEXMBX02.xlnx.xilinx.com> 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> <5670A728.8090500@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA429D65A4@XAP-PVEXMBX02.xlnx.xilinx.com> Date: Wed, 16 Dec 2015 09:57:00 -0000 Message-ID: Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation From: Richard Biener To: Ajit Kumar Agarwal Cc: Jeff Law , GCC Patches , Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg01569.txt.bz2 On Wed, Dec 16, 2015 at 8:43 AM, Ajit Kumar Agarwal wrote: > Hello Jeff: > > Here is more of a data you have asked for. > > SPEC FP benchmarks. > a) No Path Splitting + tracer enabled > Geomean Score =3D 4749.726. > b) Path Splitting enabled + tracer enabled. > Geomean Score =3D 4781.655. > > Conclusion: With both Path Splitting and tracer enabled we got maximum ga= ins. I think we need to have Path Splitting pass. > > SPEC INT benchmarks. > a) Path Splitting enabled + tracer not enabled. > Geomean Score =3D 3745.193. > b) No Path Splitting + tracer enabled. > Geomean Score =3D 3738.558. > c) Path Splitting enabled + tracer enabled. > Geomean Score =3D 3742.833. I suppose with SPEC you mean SPEC CPU 2006? Can you disclose the architecture you did the measurements on and the compile flags you used otherwise? Note that tracer does a very good job only when paired with FDO so can you re-run SPEC with FDO and compare with path-splitting enabled on top of that? Thanks, Richard. > Conclusion: We are getting more gains with Path Splitting as compared to = tracer. With both Path Splitting and tracer enabled we are also getting ga= ins. > I think we should have Path Splitting pass. > > One more observation: Richard's concern is the creation of multiple exits= with Splitting paths through duplication. My observation is, in tracer pa= ss also there > is a creation of multiple exits through duplication. I don=E2=80=99t thin= k that=E2=80=99s an issue with the practicality considering the gains we ar= e getting with Splitting paths with > more PRE, CSE and DCE. > > Thanks & Regards > Ajit > > > > > -----Original Message----- > From: Jeff Law [mailto:law@redhat.com] > Sent: Wednesday, December 16, 2015 5:20 AM > To: Richard Biener > Cc: Ajit Kumar Agarwal; GCC Patches; Vinod Kathail; Shail Aditya Gupta; V= idhumouli Hunsigida; Nagaraju Mekala > Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tr= ee ssa representation > > 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 a= n 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 profit= able. >>> 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, particu= larly >>> 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 copy= ing >> it does - after all there is sth like an instruction cache size which ex= ceeeding >> for loops will never be a good idea (and even smaller special loop cache= s 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