public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <richard.guenther@gmail.com>
To: Yuri Rumyantsev <ysrumyan@gmail.com>
Cc: Jeff Law <law@redhat.com>, Ilya Enkovich <enkovich.gnu@gmail.com>,
		gcc-patches <gcc-patches@gcc.gnu.org>,
	Igor Zamyatin <izamyatin@gmail.com>
Subject: Re: [PATCH, vec-tails 07/10] Support loop epilogue combining
Date: Mon, 05 Sep 2016 07:39:00 -0000	[thread overview]
Message-ID: <CAFiYyc23xMg083YJapCfvxmpH3pTYKuJtCxDb=ftfx-4YU++Rg@mail.gmail.com> (raw)
In-Reply-To: <CAEoMCqRYr=dUrUOa_KBPUTc=fwxUAeKQ3a1+WynxG7-MtWaadA@mail.gmail.com>

On Fri, Sep 2, 2016 at 4:46 PM, Yuri Rumyantsev <ysrumyan@gmail.com> 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 <law@redhat.com>:
>> On 08/01/2016 03:09 AM, Ilya Enkovich wrote:
>>>
>>> 2016-07-26 18:38 GMT+03:00 Ilya Enkovich <enkovich.gnu@gmail.com>:
>>>>
>>>> 2016-07-26 18:26 GMT+03:00 Jeff Law <law@redhat.com>:
>>>>>
>>>>> 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

      parent reply	other threads:[~2016-09-05  7:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-19 19:46 Ilya Enkovich
2016-06-15 11:44 ` Richard Biener
2016-06-16 15:41   ` Ilya Enkovich
2016-06-16 15:51     ` Jeff Law
2016-06-16 16:03       ` Ilya Enkovich
2016-06-16 16:54 ` Jeff Law
2016-06-28 13:37   ` Ilya Enkovich
2016-06-28 14:16     ` Ilya Enkovich
2016-07-11 13:39     ` Ilya Enkovich
2016-07-14 22:04     ` Jeff Law
2016-07-20 14:40       ` Ilya Enkovich
2016-07-20 16:24         ` Jeff Law
2016-07-21  9:15           ` Ilya Enkovich
2016-07-21 16:34             ` Jeff Law
2016-07-22 11:36               ` Richard Biener
2016-07-25 18:01                 ` Jeff Law
2016-07-25 18:33                   ` Richard Biener
2016-07-25 21:08                     ` Jeff Law
2016-07-26  9:57                       ` Ilya Enkovich
2016-07-26 11:51                         ` Richard Biener
2016-07-26 13:03                           ` Ilya Enkovich
2016-07-26 13:05                             ` Richard Biener
2016-07-26 15:26                         ` Jeff Law
2016-07-26 15:38                           ` Ilya Enkovich
2016-08-01  9:09                             ` Ilya Enkovich
2016-08-01 16:10                               ` Jeff Law
2016-09-02 14:46                                 ` Yuri Rumyantsev
2016-09-02 16:33                                   ` Bin.Cheng
2016-09-05  7:39                                   ` Richard Biener [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFiYyc23xMg083YJapCfvxmpH3pTYKuJtCxDb=ftfx-4YU++Rg@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=enkovich.gnu@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=izamyatin@gmail.com \
    --cc=law@redhat.com \
    --cc=ysrumyan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).