[PATCH] D105351: [VP] Declaration and docs for vp.select intrinsic

[Simon Moll via Phabricator via llvm-commits]

simoll added a comment.

In D105351#2919476 <https://reviews.llvm.org/D105351#2919476>, @rogfer01 wrote:

> For the case of pass-thru, does it make sense to give it a different name like `vp.overwrite` / `vp.insert` / `vp.update` / `vp.merge` (in lack of better names).  When there is pass through, this intrinsic looks to me it can be understood as first taking the whole `on_false` value and then, to build the result, selectively (as defined by the mask below the EVL) replacing elements with the corresponding values from `on_true`.

I tend to agree. Mostly, i am worried that the intrinsic id is no longer sufficient to know whether everything above `%evl` can be ignored and then there is that extra parameter. That's unnecessarily irregular.

> Then the case without pass-thru I'd call it `vp.select` because this does seem the obvious extension from the IR instruction `select` to VPred.

Agreed.

> I understood from an earlier VPred sync call that you already had considered this scheme with two intrinsics and it had some drawbacks, right? Mind to elaborate? Perhaps a vectorizer will mostly always use `vp.merge` and never `vp.select` so the latter is less interesting to have?

The original scheme had a `vp.merge` intrinsic with pivot and **no** mask and `vp.select` as you'd expect it. That was designed only with VE in mind where a select will always retain the lanes above evl.
I mostly disliked the verbosity and hoped to fuse the functionality of both in one intrinsic.
There is no way around this now that we need a concise way to express `select` with evl.
Having a `vp.merge(%m, %x, %y, %evl)` that reains lanes above evl and `vp.select(%m, %x, %y, %evl)`that doesn't would be fine though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105351