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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 27 09:39:20 PST 2017

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

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.
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/8e0a46c1/attachment.html>

More information about the llvm-dev mailing list