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

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

In D57504#1851960 <https://reviews.llvm.org/D57504#1851960>, @rkruppe wrote:

> As Eli argued in that patch, IR like `select %m, (constrained.fadd %a, %b), %passthru` is not expressing a predicated vector add, and must not be selected as such. The IR semantics are unambiguously: first a full vector add is performed (with all exceptions etc. that entails, or possible UB in related cases like integer division) and then some of the resulting lanes are replaced with values from `%passthru`. To predicate the fadd itself, a dedicated operation/intrinsic is needed. LLVM IR does not currently (and should not) change the meaning of the regular unpredicated operations based on (some? any?) uses of the value being a `select`. The only thing a `select` (or `vp.select`) can do is alter the lanes of a vector after it has been computed, it cannot travel back in time to change how it was computed.
>
> VP intrinsics are the aforementioned predicated operations: in certain lanes, no computation (which might raising FP exceptions, have UB, etc.) happens and the resulting vector has some "default value" instead. The present discussion about whether to include a `%passthru` argument is just about how this default value is determined. But this does not change that the operation itself is predicated, it just affects how you express e.g. the patterns that map to SVE's zeroing and merging predication.


Understood. I now see that we already discussed this here in October.

Your current argument sounds like it argues for explicit passthrus. E.g.:

`select %m, (vp.fadd %m, %a, %b), %zeroinitializer`

On SVE, this would become something like:

  movprfx z0.s, p0/z, z0.s
  fadd z0.s, p0/m, z0.s, z1.s

Isn't that traveling back in time to change how the inactive elements are defined? To be true to the IR. we'd want something like:

  fadd z0.s, p0/m, z0.s, z1.s
  sel z0s, p0/m, z0.s, <zero_vector> 

How do we justify that this case is different than the op+select->predicated_op case? Are we assuming the implicit undef on the VP intrinsic allows for it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504