From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62927 invoked by alias); 9 Sep 2015 21:40:13 -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 62916 invoked by uid 89); 9 Sep 2015 21:40:13 -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; Wed, 09 Sep 2015 21:40:12 +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 ABBBEC0B9890; Wed, 9 Sep 2015 21:40:10 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-28.phx2.redhat.com [10.3.113.28]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t89Le9Ex030996; Wed, 9 Sep 2015 17:40:09 -0400 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> <37378DC5BCD0EE48BA4B082E0B55DFAA41F41150@XAP-PVEXMBX02.xlnx.xilinx.com> <37378DC5BCD0EE48BA4B082E0B55DFAA41F42541@XAP-PVEXMBX02.xlnx.xilinx.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4295155D@XAP-PVEXMBX02.xlnx.xilinx.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4295ADCB@XAP-PVEXMBX02.xlnx.xilinx.com> <55D4DC4E.2020908@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4295E33C@XAP-PVEXMBX02.xlnx.xilinx.com> <55D5F6E1.3090500@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4297133F@XAP-PVEXMBX02.xlnx.xilinx.com> Cc: GCC Patches , Vinod Kathail , Shail Aditya Gupta , Vidhumouli Hunsigida , Nagaraju Mekala From: Jeff Law Message-ID: <55F0A739.3000401@redhat.com> Date: Wed, 09 Sep 2015 21:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <37378DC5BCD0EE48BA4B082E0B55DFAA4297133F@XAP-PVEXMBX02.xlnx.xilinx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00621.txt.bz2 On 08/26/2015 11:29 PM, Ajit Kumar Agarwal wrote: > > Thanks. The following testcase testsuite/gcc.dg/tree-ssa/ifc-5.c > > void dct_unquantize_h263_inter_c (short *block, int n, int qscale, > int nCoeffs) { int i, level, qmul, qadd; > > qadd = (qscale - 1) | 1; qmul = qscale << 1; > > for (i = 0; i <= nCoeffs; i++) { level = block[i]; if (level < 0) > level = level * qmul - qadd; else level = level * qmul + qadd; > block[i] = level; } } > > The above Loop is a candidate of path splitting as the IF block > merges at the latch of the Loop and the path splitting duplicates The > latch of the loop which is the statement block[i] = level into the > predecessors THEN and ELSE block. > > Due to above path splitting, the IF conversion is disabled and the > above IF-THEN-ELSE is not IF-converted and the test case fails. So I think the question then becomes which of the two styles generally results in better code? The path-split version or the older if-converted version. If the latter, then this may suggest that we've got the path splitting code at the wrong stage in the optimizer pipeline or that we need better heuristics for when to avoid applying path splitting. > > There were following review comments from the above patch. > > +/* This function performs the feasibility tests for path splitting >> + to perform. Return false if the feasibility for path splitting >> + is not done and returns true if the feasibility for path >> splitting + is done. Following feasibility tests are performed. >> + + 1. Return false if the join block has rhs casting for assign >> + gimple statements. > > Comments from Jeff: > >>> These seem totally arbitrary. What's the reason behind each of >>> these restrictions? None should be a correctness requirement >>> AFAICT. > > In the above patch I have made a check given in point 1. in the loop > latch and the Path splitting is disabled and the IF-conversion > happens and the test case passes. That sounds more like a work-around/hack. There's nothing inherent with a type conversion that should disable path splitting. What happens if we delay path splitting to a point after if-conversion is complete? Alternately, could if-conversion export a routine which indicates if a particular sub-graph is likely to be if-convertable? The path splitting pass could then use that routine to help determine if the path ought to be split or if it should instead rely on if-conversion. Jeff