[llvm-dev] [Proposal][RFC] Epilog loop vectorization

[Daniel Berlin via llvm-dev]

On Mon, Feb 27, 2017 at 12:01 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 02/27/2017 01:47 PM, Daniel Berlin wrote:
>
>
>
> On Mon, Feb 27, 2017 at 11:29 AM, Adam Nemet <anemet at apple.com> wrote:
>
>>
>> On Feb 27, 2017, at 10:11 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>>
>>
>> On 02/27/2017 11:47 AM, Adam Nemet wrote:
>>
>>
>> On Feb 27, 2017, at 9:39 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>>
>>
>> On Mon, Feb 27, 2017 at 9:29 AM, Adam Nemet <anemet at apple.com> wrote:
>>
>>>
>>> On Feb 27, 2017, at 7:27 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>>>
>>>
>>> On 02/27/2017 06:29 AM, Nema, Ashutosh wrote:
>>>
>>> Thanks for looking into this.
>>>
>>> 1) Issues with re running vectorizer:
>>> Vectorizer might generate redundant alias checks while vectorizing
>>> epilog loop.
>>> Redundant alias checks are expensive, we like to reuse the results of
>>> already computed alias checks.
>>> With metadata we can limit the width of epilog loop, but not sure about
>>> reusing alias check result.
>>> Any thoughts on rerunning vectorizer with reusing the alias check result
>>> ?
>>>
>>>
>>> One way of looking at this is: Reusing the alias-check result is really
>>> just a conditional propagation problem; if we don't already have an
>>> optimization that can combine these after the fact, then we should.
>>>
>>>
>>> +Danny
>>>
>>> Isn’t Extended SSA supposed to help with this?
>>>
>>
>> Yes, it will solve this with no issue already.  GVN probably does already
>> too.
>>
>> even if if you have
>>
>> if (a == b)
>> if (a == c)
>>  if (a == d)
>>  if (a == e)
>>  if (a == g)
>>
>>
>> and  we can prove a ... g equivalent, newgvn will eliminate them all and
>> set all the branches true.
>>
>> If you need a simpler clean up pass, we could run it on sub-graphs.
>>
>>
>> Yes we probably don’t want to run a full GVN after the “loop-scheduling”
>> passes.
>>
>>
>> FWIW, we could, just without the memory-dependence analysis enabled (i.e.
>> set the NoLoads constructor parameter to true). GVN is pretty fast in that
>> mode.
>>
>>
>> OK.  Another data point is that I’ve seen cases in the past where the
>> alias checks required for the loop passes could enable GVN to remove
>> redundant loads/stores.  Currently we can only pick these up with LTO when
>> GVN is rerun.
>>
>
> This is just GVN brokenness, newgvn should not have this problem.
> If it does, i'd love to see it.
>
>
> I thought that the problem is that we just don't run GVN after that point
> in the pipeline.
>
> Then i misunderstand.

"Another data point is that I’ve seen cases in the past where the alias
checks required for the loop passes could enable GVN to remove redundant
loads/stores."

Why would GVN suddenly be able to remove redundant loads and stores due to
insertion of alias checks?

It should have been able to remove them regardless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170227/47d97e51/attachment.html>