From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47938 invoked by alias); 15 Jan 2016 23:02:33 -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 47914 invoked by uid 89); 15 Jan 2016 23:02:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1936, answered, replying 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; Fri, 15 Jan 2016 23:02:32 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 12E2A746; Fri, 15 Jan 2016 23:02:31 +0000 (UTC) Received: from slagheap.utah.redhat.com (ovpn-113-225.phx2.redhat.com [10.3.113.225]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0FN2UoB016458; Fri, 15 Jan 2016 18:02:30 -0500 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> <5696068E.7070604@redhat.com> <56976289.3080203@redhat.com> Cc: GCC Patches , Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala From: Jeff Law Message-ID: <56997A86.7070201@redhat.com> Date: Fri, 15 Jan 2016 23:02: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: <56976289.3080203@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01164.txt.bz2 On 01/14/2016 01:55 AM, Jeff Law wrote: [ Replying to myself again, mostly to make sure we've got these thoughts in the archives. ] > > Anyway, going back to adpcm_decode, we do end up splitting this path: > > # vpdiff_12 = PHI > if (sign_41 != 0) > goto ; > else > goto ; > ;; succ: 15 > ;; 16 > > ;; basic block 15, loop depth 1 > ;; pred: 14 > valpred_51 = valpred_76 - vpdiff_12; > goto ; > ;; succ: 17 > > ;; basic block 16, loop depth 1 > ;; pred: 14 > valpred_52 = vpdiff_12 + valpred_76; > ;; succ: 17 > > ;; basic block 17, loop depth 1 > ;; pred: 15 > ;; 16 > # valpred_7 = PHI > _85 = MAX_EXPR ; > valpred_13 = MIN_EXPR <_85, 32767>; > step_53 = stepsizeTable[index_62]; > outp_54 = outp_69 + 2; > _55 = (short int) valpred_13; > MEM[base: outp_54, offset: -2B] = _55; > if (outp_54 != _74) > goto ; > else > goto ; > > This doesn't result in anything particularly interesting/good AFAICT. We > propagate valpred_51/52 into the use in the MAX_EXPR in the duplicate > paths, but that doesn't allow any further simplification. So with the heuristic I'm poking at, this gets rejected. Essentially it doesn't think it's likely to expose CSE/DCE opportunities (and it's correct). The number of statements in predecessor blocks that feed operands in the to-be-copied-block is too small relative to the size of the to-be-copied-block. > > Ajit, can you confirm which of adpcm_code or adpcm_decode where path > splitting is showing a gain? I suspect it's the former but would like > to make sure so that I can adjust the heuristics properly. I'd still like to have this answered when you can Ajit, just to be 100% that it's the path splitting in adpcm_code that's responsible for the improvements you're seeing in adpcm. jeff