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

[Robin Kruppe via Phabricator via llvm-commits]

rkruppe added a comment.

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

> Ok. I do agree that having passthru simplifies isel for certain architectures (and legal combinations of passthru value,  type, and operations..) but:
>  VP intrinsics aren't target intrinsics: they are not supposed to be a way to directly program any specific ISA in the way of a macroassembler, like you would do with `llvm.x86.*` or `llvm.arm.mve.*` or any other. Rather, think of them as regular IR instructions. Pretend that anything we propose in VP intrinsics will end up as a feature of a first-class LLVM instructions. Based on that i figured that one VP intrinsics should match one IR instructions plus predication, nothing more.
>
> - If we had predicated IR instructions, would we want them to have a passthru operand?


I think that would probably be a reasonable clean-slate IR design, though I am not at all sure if it would be //better//. I wasn't specifically advocating for passthru operands, though. I agree that not having passthru and performing the same function in two operations can be readily pattern-matched by backends at modest effort and failing to match it has low cost. My main point was just that the existing `select` instruction is not sufficient as the second operation, for essentially the same reason why the VP intrinsics have an EVL argument instead of just the mask. Creating a VP equivalent of `select` (as already sketched in the other thread) resolves that concern just as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504