From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79835 invoked by alias); 5 Sep 2016 07:21:45 -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 79821 invoked by uid 89); 5 Sep 2016 07:21:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=enkovich.gnu@gmail.com, enkovichgnugmailcom, ysrumyan@gmail.com, ysrumyangmailcom X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Sep 2016 07:21:43 +0000 Received: by mail-wm0-f49.google.com with SMTP id w12so24251239wmf.0 for ; Mon, 05 Sep 2016 00:21:42 -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=qPs7v0lqMV7NEOokgFFPJk3fKRSsqLcFkEztOFJ7C18=; b=URAowHzj+U9s/lmyUBm5tsSW4BMZ/6H6JPXbkcWTFJj5H8rxTr9CymI7Q/Vd3XVF+o QFTP3P+lVRiYTiUqOYD/tEWxQniho4ftHCvNP11YG7pYTP+/F/Al8CIqgn4zDFseR9so ebOlalQDeVgSOMQJnzKrzav99CHWKUQiStosT+sDA7u9srYdB6VG9UK4UkCNPPoXUA8G H09H5wk96XZV774PMJ1KSGZcpp/wUOMu347LJaeA77LlGoOKvIkQke9hj8GQmk9r+Hz1 mYaYnO31ZfM19xdqjymyzoJTdfrSFnzOgKCh7c9epOPvNWYNPkDkJbm2iQU4GbxbzaCK LetA== X-Gm-Message-State: AE9vXwMYKwRbJOgfwUsq84RhL86JxQH9Uamm+YuS9J0MmvAsbrHRYAtEWn+AR1GaRV4DNCIT2Unf/R3jhbLoYw== X-Received: by 10.28.139.144 with SMTP id n138mr13294060wmd.71.1473060100884; Mon, 05 Sep 2016 00:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Mon, 5 Sep 2016 00:21:39 -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> <37fbe5e6-6e44-ffff-5467-21e162919586@redhat.com> <44d301f6-3fce-e32e-ad4b-a2440596b99e@redhat.com> From: Richard Biener Date: Mon, 05 Sep 2016 07:39:00 -0000 Message-ID: Subject: Re: [PATCH, vec-tails 07/10] Support loop epilogue combining To: Yuri Rumyantsev Cc: Jeff Law , Ilya Enkovich , gcc-patches , Igor Zamyatin Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00184.txt.bz2 On Fri, Sep 2, 2016 at 4:46 PM, Yuri Rumyantsev wrote: > Hi Jeff, > > I am trying to reduce cost of repeated call of if-conversion for > epilogue vectorization. I'd like to clarify your recommendation - > should I design additional support for versioning in > vect_do_peeling_for_loop_bound or lightweight version of if-conversion > is sufficient? Any help in clarification will be appreciated. For general infrastructure it would be nice to expose a (post-)dominator compute for MESE (post-dominators) / SEME (dominators) regions. I believe what makes if-conversion expensive is the post-dom compute which happens for each loop for the whole function. It shouldn't be very difficult to write this, sharing as much as possible code with the current DOM code might need quite some refactoring though. If you want to avoid this work then you have to go the versioning route. Richard. > Thanks ahead. > Yuri. > > 2016-08-01 19:10 GMT+03:00 Jeff Law : >> On 08/01/2016 03:09 AM, Ilya Enkovich wrote: >>> >>> 2016-07-26 18:38 GMT+03:00 Ilya Enkovich : >>>> >>>> 2016-07-26 18:26 GMT+03:00 Jeff Law : >>>>> >>>>> On 07/26/2016 03:57 AM, Ilya Enkovich wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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. >>>>> >>>>> >>>>> Right. So what I think Richi wants you to try is to use the >>>>> if-converted >>>>> loop to construct the if-converted epilogue. It seems conceptually >>>>> simple >>>>> and low cost -- the question is on the implementation side. I have no >>>>> clue >>>>> how painful that would be. >>>> >>>> >>>> Probably another part of if-conversion may be re-used to build required >>>> epilogue. I'll have a look. >>> >>> >>> Hi, >>> >>> Yuri will continue my work from this point. >> >> Understood. I'm actually got some comments on #5 and Yuri is already on the >> CC list for that draft message. >> >> Jeff