From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27261 invoked by alias); 4 Feb 2016 08:57:29 -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 27246 invoked by uid 89); 4 Feb 2016 08:57:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=1.35, diamond, Neither, 2503 X-HELO: mail-qg0-f68.google.com Received: from mail-qg0-f68.google.com (HELO mail-qg0-f68.google.com) (209.85.192.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 08:57:26 +0000 Received: by mail-qg0-f68.google.com with SMTP id b35so2305555qge.2 for ; Thu, 04 Feb 2016 00:57:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=nZ/s0KojRAm6wqU0FQzRTVmEuzizrtZPW0gYVByKGI0=; b=ic6iFQiLyEMTE4BpwpF4pLcuF6aFwnLOqEPR1DqIbkPAkD/N7c4gyl54LjRCrzDBRX 3QFCz68SlMB225mGTEa8UchpLWlNyIPPAzEfFdEDs5uHmKwQ3rULeaqVvFNENV74ZHoB 9luLktudnPh27Ki91c+3OQp8clOKL9IpiHsNeWKFWvoJ9rl7G0Zo8mUmFvishFXGBjtb l6Cm4sq2xO1pn11n7u7UwmgG2lm51AQSomC0didyhzTAF4Wq28LZWdjNir3vbuhqojN+ D7piox3kzLKvguLuTg4udHRzSLKaGnrR5WidXDEaxSxiutqR1MqU/VtvRHsrUgO524Gf 6xyQ== X-Gm-Message-State: AG10YOSBiX+69Gw9w2l2KSYDmqoO69VHAybd/3243VDX4pyhWvU/fFunYRjg18rnFK7bJw== X-Received: by 10.140.239.65 with SMTP id k62mr7974410qhc.11.1454576244694; Thu, 04 Feb 2016 00:57:24 -0800 (PST) Received: from slagheap.utah.redhat.com (c-24-11-92-212.hsd1.ut.comcast.net. [24.11.92.212]) by smtp.googlemail.com with ESMTPSA id e28sm4504901qkh.44.2016.02.04.00.57.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 00:57:23 -0800 (PST) From: Jeff Law X-Google-Original-From: Jeff Law Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation To: Ajit Kumar Agarwal , Richard Biener References: <37378DC5BCD0EE48BA4B082E0B55DFAA41F3F56C@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> <37378DC5BCD0EE48BA4B082E0B55DFAA429D4950@XAP-PVEXMBX02.xlnx.xilinx.com> <567A40E4.1030508@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA429DED02@XAP-PVEXMBX02.xlnx.xilinx.com> Cc: GCC Patches , Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala Message-ID: <56B31272.1000207@gmail.com> Date: Thu, 04 Feb 2016 08:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <37378DC5BCD0EE48BA4B082E0B55DFAA429DED02@XAP-PVEXMBX02.xlnx.xilinx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00272.txt.bz2 On 01/04/2016 07:32 AM, Ajit Kumar Agarwal wrote: > > > -----Original Message----- > From: Jeff Law [mailto:law@redhat.com] > Sent: Wednesday, December 23, 2015 12:06 PM > To: Ajit Kumar Agarwal; Richard Biener > Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation > > On 12/11/2015 02:11 AM, Ajit Kumar Agarwal wrote: >> >> Mibench/EEMBC benchmarks (Target Microblaze) >> >> Automotive_qsort1(4.03%), Office_ispell(4.29%), Office_stringsearch1(3.5%). Telecom_adpcm_d( 1.37%), ospfv2_lite(1.35%). >>> I'm having a real tough time reproducing any of these results. In fact, I'm having a tough time seeing cases where path splitting even applies to the Mibench/EEMBC benchmarks >>mentioned above. > >>> In the very few cases where split-paths might apply, the net resulting assembly code I get is the same with and without split-paths. > >>> How consistent are these results? > > I am consistently getting the gains for office_ispell and office_stringsearch1, telcom_adpcm_d. I ran it again today and we see gains in the same bench mark tests > with the split path changes. > >>> What functions are being affected that in turn impact performance? > > For office_ispell: The function are Function "linit (linit, funcdef_no=0, decl_uid=2535, cgraph_uid=0, symbol_order=2) for lookup.c file". > "Function checkfile (checkfile, funcdef_no=1, decl_uid=2478, cgraph_uid=1, symbol_order=4)" > " Function correct (correct, funcdef_no=2, decl_uid=2503, cgraph_uid=2, symbol_order=5)" > " Function askmode (askmode, funcdef_no=24, decl_uid=2464, cgraph_uid=24, symbol_order=27)" > for correct.c file. > > For office_stringsearch1: The function is Function "bmhi_search (bmhi_search, funcdef_no=1, decl_uid=2178, cgraph_uid=1, symbol_order=5)" > for bmhisrch.c file. In linit there are two path splitting opportunities. Neither of them are cases where path splitting exposes any CSE or DCE opportunities at the tree level. In fact, in both cases there are no operands from the predecessors that feed into the join (that we duplicate the split the path). There's a path splitting opportunity in correct.c::givehelp which AFAICT is totally uninteresting from a performance standpoint. However, these are one of the few cases where path splitting actually results in something that is better optimized at the tree level. How ironic. We'd easily get the same result by sinking a statement down through a PHI in a manner similar to what's been suggested for 64700. In correct.c::checkfile and correct.c::correct and correct.c::askmode the path splitting opportunities do not lead to any further simplifications at the gimple level. Similarly for bmhisrch.c::bmhi_search. So when I look across all these examples, the only one that's really a CSE/DCE opportunity exposed by path splitting that is performance important is adpcm_code. The rest, AFAICT, benefit at a much lower level -- a diamond in the CFG will require an unconditional branch from the end of one arm around the other arm to the join point. With path splitting that unconditional branch is eliminated. So there's a small gain for that. That gain may be even larger on the microblaze because of its exposed delay slot architecture -- one less slot to fill. It may also result in better code layouts which help simplistic branch predictors. So I find myself wondering if the primary effect we're looking for most of the time is really elimination of that unconditional branch. And if it is the case, then we're looking at a very different costing heuristic -- one that favors very small join blocks rather than larger ones (that supposedly help expose CSE/DCE, but in reality aren't for the benchmarks I've looked at). And if that's the case, then we may really be looking at something that belongs at the RTL level rather than at the tree/gimple level. Sadly, it's harder to do things like duplicate blocks at the RTL level. Anyway, I'm going to ponder some more. jeff