From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31152 invoked by alias); 12 Nov 2015 19:40:09 -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 31141 invoked by uid 89); 12 Nov 2015 19:40:09 -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-wm0-f54.google.com Received: from mail-wm0-f54.google.com (HELO mail-wm0-f54.google.com) (74.125.82.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 12 Nov 2015 19:40:08 +0000 Received: by wmec201 with SMTP id c201so49929515wme.0 for ; Thu, 12 Nov 2015 11:40:05 -0800 (PST) X-Received: by 10.28.174.144 with SMTP id x138mr48844411wme.28.1447357205481; Thu, 12 Nov 2015 11:40:05 -0800 (PST) Received: from android-4c5a376a18c0e957.fritz.box (p4FE9C0B8.dip0.t-ipconnect.de. [79.233.192.184]) by smtp.gmail.com with ESMTPSA id u4sm9692055wjz.4.2015.11.12.11.40.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 11:40:04 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <5644DB59.9040809@redhat.com> 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> <55D4F921.2020708@redhat.com> <37378DC5BCD0EE48BA4B082E0B55DFAA4297704C@XAP-PVEXMBX02.xlnx.xilinx.com> <5643A732.4040707@redhat.com> <5644C6CC.90203@redhat.com> <5644DB59.9040809@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation From: Richard Biener Date: Thu, 12 Nov 2015 19:40:00 -0000 To: Jeff Law CC: Ajit Kumar Agarwal ,GCC Patches ,Vinod Kathail ,Shail Aditya Gupta ,Vidhumouli Hunsigida ,Nagaraju Mekala Message-ID: <78105CCE-6EFB-4D03-ADDF-DF7354110CB2@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01583.txt.bz2 On November 12, 2015 7:32:57 PM GMT+01:00, Jeff Law wrote: >On 11/12/2015 10:05 AM, Jeff Law wrote: >>> But IIRC you mentioned it should enable vectorization or so? In >this >>> case >>> that's obviously too late. >> The opposite. Path splitting interferes with if-conversion & >> vectorization. Path splitting mucks up the CFG enough that >> if-conversion won't fire and as a result vectorization is inhibited. >It >> also creates multi-latch loops, which isn't a great situation either. >> >> It *may* be the case that dropping it that far down in the pipeline >and >> making the modifications necessary to handle simple latches may in >turn >> make the path splitting code play better with if-conversion and >> vectorization and avoid creation of multi-latch loops. At least >that's >> how it looks on paper when I draw out the CFG manipulations. >> >> I'll do some experiments. >It doesn't look too terrible to ravamp the recognition code to work >later in the pipeline with simple latches. Sadly that doesn't seem to >have fixed the bad interactions with if-conversion. > >*But* that does open up the possibility of moving the path splitting >pass even deeper in the pipeline -- in particular we can move it past >the vectorizer. Which is may be a win. > >So the big question is whether or not we'll still see enough benefits >from having it so late in the pipeline. It's still early enough that >we >get DOM, VRP, reassoc, forwprop, phiopt, etc. > >Ajit, I'll pass along an updated patch after doing some more testing. BTW, if you not use loops_normal for loop init you don't get simple latches forced (and cfg-cleanup will remove them) Richard. >Jeff