[PATCH] D57504: RFC: Prototype & Roadmap for vector predication in LLVM

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

In D57504#1723466 <https://reviews.llvm.org/D57504#1723466>, @simoll wrote:

> In D57504#1720792 <https://reviews.llvm.org/D57504#1720792>, @shawnl wrote:
>
> > Are predicated vector instructions not just a special case of DemandedBits? Why can't we leave out the .vp. intrinsics, and just generate the predicate with DemandedBits? That way you do a predicated vector operation like so (in zig): As the example makes clear, this optimization would have to be guaranteed in order for the generated code to be correct (as the predicate avoids a divide-by-zero error).
> >
> > var notzero = v != 0;
> >  if (std.vector.any(notzero)) {
> >
> >   v = std.vector.select(5 / v, v, notzero);
> >
> > }
>
>
> What you describe is a workaround but not a solution for predicated SIMD in LLVM.
>  This approach may seem natural considering SIMD ISAs, such as x86 SSE, ARM NEON, that do not have predication.
>  It is however a bad fit for SIMD instruction sets that do support predicated SIMD (AVX512, ARM SVE, RISC-V V, NEC SX-Aurora).
>
> As it turns out, it is more robust to have predicated instructions right in LLVM IR and convert them to the instruction+select pattern for SSE and friends than going the other way round.
>  This is what LLVM-VP proposes.


+1 on what Simon said.

There are lots of peeps like:

`select ?, X, undef -> X`

If we optimize away the select, we could end up incorrectly trapping on the no longer masked bits of X. This would be bad for the constrained intrinsics.

But also in the general case, it's very hard to keep a select glued to an operation through opt and llc.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504