From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58805 invoked by alias); 26 Jul 2016 13:03:11 -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 58788 invoked by uid 89); 26 Jul 2016 13:03:10 -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=Calling, enkovich.gnu@gmail.com, enkovichgnugmailcom, H*i:sk:Q@mail. X-HELO: mail-ua0-f182.google.com Received: from mail-ua0-f182.google.com (HELO mail-ua0-f182.google.com) (209.85.217.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 26 Jul 2016 13:03:03 +0000 Received: by mail-ua0-f182.google.com with SMTP id k90so1507754uak.0 for ; Tue, 26 Jul 2016 06:03:03 -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=YzMyJeZCUnQOVjzrDE/KwNwz6X5GXKRB1TXUdC1CQKI=; b=hpYnK+Ef56vSehTHuFD3Lm7HYJjT7TBcH0Cvx/F+JNCUujv+DzSJMJSyM+dDCJ8KmU y7QAW3fqAc8SY+TiFAsTBaBSY1Wm2vGw4QrfuKiHgnEq4Y4w3sciEmbPiHA8WGznRzS5 1MapgFMcBRT73f4hADOkD8OX4zHfGfX8Eu+uqqnkjPkfxtiapysiygVwNjwJLKGktFww 7fjKnbGagyrXq1KVcNw0OVGp/iiV1x7MkmbDg4NbvQbn9N8JsFhmXp4M5IM86QUL5eB3 5dYfywhGL07qHFtZsIe15QXMmuZWHcsnNhDLP5ziGzL5lnn1oc6qPU5tcBc4v7EHeCZP F75g== X-Gm-Message-State: AEkoouvRKiZeLak2e+EeHTfel6cEixqGrx4j/1szYtQxh9xGzHOJgX6lI6fb8CvQdt9yW51gTCI82UzHIDu8Gw== X-Received: by 10.159.55.168 with SMTP id q37mr10590195uaq.1.1469538181580; Tue, 26 Jul 2016 06:03:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.244 with HTTP; Tue, 26 Jul 2016 06:03:00 -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: Ilya Enkovich Date: Tue, 26 Jul 2016 13:03:00 -0000 Message-ID: Subject: Re: [PATCH, vec-tails 07/10] Support loop epilogue combining To: Richard Biener Cc: Jeff Law , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg01707.txt.bz2 2016-07-26 14:51 GMT+03:00 Richard Biener : > 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. > Agree. Calling if-conversion is just much simpler in implementation. Thanks, Ilya > I see no need to re-run if-conversion here. > > Richard. > >> Thanks, >> Ilya >> >>> >>> Jeff