[llvm-dev] [Proposal][RFC] Epilog loop vectorization
Adam Nemet via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 27 09:47:24 PST 2017
> 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.
> 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.
> 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...
More information about the llvm-dev