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

[Simon Moll via Phabricator via llvm-commits]

simoll marked an inline comment as done.
simoll added a comment.

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

> (This was gonna be an inline comment on D69891 <https://reviews.llvm.org/D69891>, but it's more of a general conceptual issue, so I decided to move it here.)
>
> Right now, LangRef changes in D69891 <https://reviews.llvm.org/D69891> describe the restriction on the EVL value as this:
>
> > The explicit vector length (%evl) is only effective if it is non-negative, and when that is the case, its value is in the range:
> > 
> >   0 <= %evl <= W,   where W is the vector length.
>
> The restriction is good, but this wording doesn't specify what happens when `%evl` is not in that range. Some sort of undefined behavior, I assume, but this must be explicitly stated, especially since there are many ways in which it could be undefined. I don't recall previous discussion of this detail and I don't know what you have in mind, but some possibilities I see:
>
> 1. The instruction has capital-UB undefined behavior. This gives the greatest flexibility to backends (e.g., allows generation of code that traps if %evl is too large) but I don't know of any architecture that needs this much flexibility and it constrains IR optimizations (code hoisting etc.) the most.


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.
Besides, this still allows you to speculate as long as MVL (as in the UB-causing bound for VL) does not go below VL... could you explain under which circumstance MVL would go below VL by hoisting? This is definitely not the case for static VL targets (x86) and also not for VE.

TODO:
-----

- Define behavior for `%evl > W`
- Amend that `W` is target specific.



================
Comment at: llvm/docs/Proposals/VectorPredication.rst:2
+==========================
+Vector Predication Roadmap
+==========================
----------------
andrew.w.kaylor wrote:
> Is there any reason that some form of this document can't be committed now? We have at least enough support to claim this as a community wide proposal, right?
I think so. I'll put the proposal doc up for review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504