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

[Adam Nemet via llvm-dev]

> 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 <mailto:anemet at apple.com>> wrote:
> 
>> On Feb 27, 2017, at 7:27 AM, Hal Finkel <hfinkel at anl.gov <mailto: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.

I guess the pipeline to experiment with for now is opt -loop-vectorize -loop-vectorize -newgvn.

Adam

> The only thing you'd have to do is write some code to set "live on entry" subgraph variables in their own congruence classes.
> We already do this for incoming arguments.
> 
> Otherwise, it's trivial to make it only walk things in the subgraph.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170227/36ec6dae/attachment.html>