[PATCH] D108281: [GVN] Improve alias analysis for parallel accesses

Alban Bridonneau via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 20 01:15:05 PDT 2021


alban.bridonneau added a comment.

Thank you for the clarifications!
I see now that the llvm.loop.parallel_accesses metadata can't be used in the way that we wanted. We have also come back to the original IR and found that there was a more appropriate way to tackle our issue. So I'll close this review. I'll also add a bit more information about our case below, in case you're interested.

Our case is basically the one shown in the unit test:

  x1 = load @x 
  store @y
  x2 = load @x

We should be able to eliminate the 2nd load, but we can only do that if we know that it is not aliasing with the store.
The issue we tried to solve, is that we manage to do the elimination of the load when the loop is written simply, but if we use a pragma simd, and annotate the loop as parallel, we are not managing to eliminate the load. So the pragma that we use to create better performance is actually having the opposite effect.

We're going to work next on the Loop Vectorizer. When the loop is annotated parallel, the vectorizer doesn't create any runtime checks and just vectorizes. Without the parallel annotation, we create runtime memory checks, version the loop, and the Loop Vectorizer creates new metadata on the memory accesses (noalias/alias.scope). This is what we want to use in order to do more load elimination. Even though nothing is needed for vectorization, we might want some level of runtime checks in order to further optimize the vectorized loop.
That's the basic idea anyway, we'll need to work on it, to figure out exactly what to do.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108281/new/

https://reviews.llvm.org/D108281



More information about the llvm-commits mailing list