[llvm-dev] [Proposal][RFC] Epilog loop vectorization
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 27 10:11:52 PST 2017
On 02/27/2017 11:47 AM, Adam Nemet wrote:
>> On Feb 27, 2017, at 9:39 AM, Daniel Berlin <dberlin at dberlin.org
>> <mailto: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.
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.
> 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.
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev