[PATCH] D99750: [LV, VP] RFC: VP intrinsics support for the Loop Vectorizer (Proof-of-Concept)

Fri May 19 07:38:25 PDT 2023

loralb added a comment.

> Checked the poster, actually it is pretty similar to the proposed patch, and, most probably, can be reused by their approach too. @rogfer01?

(Roger asked me to answer on his behalf as I have been more directly involved in the poster PoC).

There is a difference, though. In the PoC presented in the poster we do not use vector predication in the loop vectoriser except for load/store/gather/scatter. We rely on a later pass to propagate the demaned EVL and mask (for now starting from `vp.store` / `vp.scatter`) and replace vector IR instructions (and other whole vector intrinsics like `llvm.fmuladd`) with VP-intrinsics.

Now the question that remains is: what would be the best way forward? Either we teach Loop Vectorizer about VP intrinsics for IR instructions like your PoC is doing, or we make the minimal change for correctness (mostly memory accesses and things like integer divisions) and leave the choice to use vector predication to the target. For instance, a machine with long vectors (such as VE) the latency is typically driven by the vector length so it is worth propagating the EVL to all the instructions. For more traditional SIMD-like designs (with a data-path that is wide enough for the vector instruction) vector length may be less relevant and using the whole vector may be performant enough.

Now, with this PoC two modes are possible. One mode "vector-length-full" (this is, like your PoC) and another mode "vector-length-only-correctness" (the first part of our PoC, without using any further pass). The former mode is a superset of the latter. On our side, both modes are ok; by the quick conversation I had with @fhahn at EuroLLVM, I got the impression he would prefer the latter, but better wait for his input.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99750