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

[Simon Moll via Phabricator via llvm-commits]

simoll added a comment.

In D57504#1856207 <https://reviews.llvm.org/D57504#1856207>, @andrew.w.kaylor wrote:

> In D57504#1854330 <https://reviews.llvm.org/D57504#1854330>, @simoll wrote:
>
> > Exactly. The VE target strictly requires `VL <= MVL` or you'll get a hardware exception. Enforcing strict UB here means VP-users have to explicitly drop instructions that keep the VL within bounds. This means that we can optimize the VL computation code and that it can be factored into cost calculations, etc. With Options 2 & 3 this would happen only very late in the backend when most scalar optimizations are already done.
>
>
> I think I'm lost here. Which thing is VL and which is MVL in this scenario?


VL == %evl
MVL == W
Sorry for the vector speak :)

> Also, the talk about how various hardware treats the relative values of VL and MVL concerns me if either of these is supposed to be the width of the vector passed to this intrinsic. My understanding is that we're supposed to be able to generate vectors of any width we want in IR and the type legalization is responsible for mapping that to vector sizes that are legal for the target. So what does the target requirement mean here?

I agree that, in the end, the semantics will be based solely on IR-types. However, what that semantics should look like for the `%evl > W` case depends on the way targets can handle this to make sure that whatever we specify on IR-level is at least reasonable for all targets.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504