From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43606 invoked by alias); 26 Jul 2016 11:51:30 -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 43578 invoked by uid 89); 26 Jul 2016 11:51:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=2016-07-26, opportunity X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 26 Jul 2016 11:51:28 +0000 Received: by mail-wm0-f46.google.com with SMTP id i5so12891190wmg.0 for ; Tue, 26 Jul 2016 04:51:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=otT9YQZMStijfLj7jfxwaNjhgX597RqAR4dAVo3ULg4=; b=ft2KwDWtBeT7UQ1w91wy+rFKoSPuFULgzirVIYOtryihIIEL58r6QWiNGfNmmmpu8F GSRKHku8xbkK9wHfacYsLuA7p4ooMgfgaVv1mfYT+ABIHjWAKyalUbo6LBb/KChWzB3d ymXYORkvVqbZ5kyy/EFkUbBFkdwDIf6Fm5WHgokQ9bxIxvALyfBvATke9FUNjNEYVmab rwfY4aRe6LR7Yrt7FC5WAjmgdfDtMCm8Oiz7pP+Hz8dXU+PotD87bn6HpAYNb45hP5vt kqrocU79CDDvWAwJ/gmrRGIdxvjEf1MMuIEieDSRMZM5kR/Hiy9ycbho5+GR5nGzYBm7 9M/Q== X-Gm-Message-State: AEkooutj/FbI0tRrQGiR4aOdCksW04QoReC6RnfnyRz5dimLZ0370EzdRSERcASTslp3o1ZbTayMlAfv0xwYqA== X-Received: by 10.194.58.112 with SMTP id p16mr20880886wjq.24.1469533885389; Tue, 26 Jul 2016 04:51:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Tue, 26 Jul 2016 04:51:24 -0700 (PDT) In-Reply-To: References: <20160519194450.GH40563@msticlxl57.ims.intel.com> <18ccae1a-30c3-c23c-e28f-287f9d41eaa0@redhat.com> <20160628122439.GB4143@msticlxl57.ims.intel.com> <20160720143705.GA2605@msticlxl57.ims.intel.com> <4bb744cb-92df-ca29-54e2-82162216e88c@redhat.com> <5cacdc29-e916-f460-3c44-5fa6450a24a9@redhat.com> From: Richard Biener Date: Tue, 26 Jul 2016 11:51:00 -0000 Message-ID: Subject: Re: [PATCH, vec-tails 07/10] Support loop epilogue combining To: Ilya Enkovich Cc: Jeff Law , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg01698.txt.bz2 On Tue, Jul 26, 2016 at 11:57 AM, Ilya Enkovich wrote: > 2016-07-26 0:08 GMT+03:00 Jeff Law : >> On 07/25/2016 12:32 PM, Richard Biener wrote: >>> >>> On July 25, 2016 8:01:17 PM GMT+02:00, Jeff Law wrote: >>>> >>>> On 07/22/2016 05:36 AM, Richard Biener wrote: >>>>> >>>>> The thing that needs work I think is re-running of if-conversion. >>>> >>>> I wonder if we could revamp if-conversion to work on a subset of the >>>> CFG? I can see that potentially being useful in other contexts. >>>> Would >>>> that work for you Richi? >>> >>> >>> Well, you need to make it not need post-dominators or preserve them (or >>> compute "post-dominators" on SESE regions). >> >> Oh, but it'd be so nice to have DOMs and/or PDOMs on regions. But that's >> probably out of scope for gcc-7. >> >> >>> >>> What doesn't work with the idea to clone the epilogue using >>> __built-in_vectorized() >>> For the if- vs. Not if-converted loop? >> >> I must be missing something. I don't see how builtin_vectorized_function >> helps, but maybe I've got the wrong built-in or don't understand what you're >> suggesting. >> >> It sounds like this is the biggest impediment to moving forward. So let's >> reset and make sure we're all on the same page here. >> >> Ilya, what's the fundamental reason why we need to run if-conversion again? >> Yes, I know you want to if-convert the epilogue, but why? >> >> What are the consequences of not doing if-conversion on the epilogue? >> Presumably we miss a vectorization opportunity on the tail. But that may be >> a reasonable limitation to allow the existing work to move forward while you >> go back and revamp things a little. > > If we have some control-flow in a loop then we have to if-convert it > for vectorizer. > We need to preserve both versions: if-converted one for vectorizer and > the original > one to be used if vectorization fails. For epilogues we have similar > situation and > need two versions. I do it by running if-conversion on a copy of original loop. > Note that it doesn't run full if-conversion pass. If-conversion is > called for epilogue > loop only. But it will still compute post-dominators for the full function for example. You have the if-converted loop available already - it's the loop we are going to vectorize. If if-conversion generated if (__builtin_vectorized_p ()) style loop copies then you can simply create the epilogue in the same way. If it didn't then the loop is already if-converted anyway. I see no need to re-run if-conversion here. Richard. > Thanks, > Ilya > >> >> Jeff