This patch implements vector-predicated intrinsics on IR level for fadd,  fsub, fmul, fdiv and frem.
There operate in the default floating-point environment. We will use constrained fp operand bundles for constrained vector-predicated fp math (D93455).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
| llvm/include/llvm/IR/VPIntrinsics.def | ||
|---|---|---|
| 174 | .. fsub is missing here.. i will supplement it and add a unit test to check the integrity of the VPIntrinsics.def file. | |
| llvm/docs/LangRef.rst | ||
|---|---|---|
| 18272 | I realise this inherits from the documentation of the integer intrinsics, but I was wondering if this can be expressed as being equivalent to <%evl x float> in the following example. Would that be any clearer that the intrinsic is conceptually working on vectors of length %evl isn't actually executing the lanes above %evl (as in %t below)? | |
| 18296 | addition -> subtraction | |
| 18310 | same here: addition and maybe add <i_fsub>? | |
| 18345 | addition -> multiplication | |
| 18359 | addition -> multiplication | |
| 18394 | addition -> division | |
| 18408 | same here | |
| 18443 | addition -> remainder | |
| 18457 | addition -> remainder | |
| llvm/include/llvm/IR/VPIntrinsics.def | ||
| 162 | integer -> floating-point? | |
| llvm/docs/LangRef.rst | ||
|---|---|---|
| 18272 | I see what are you getting at with this. I am not sure that introducing novel syntax only for explaining things is really helpful. My take here is that most aren't used to the %evl concept - but it is not a complicated thing per se. | |
The unit test changes in this patch depend on the cleanup work done in D93534 . Please have a look at that one too!
With D93534 out of the way, we should have cleared all hurdles for this one. Where do we stand, comments, LGTMs?
| llvm/docs/LangRef.rst | ||
|---|---|---|
| 18275 | Would it be more general/useful to have the intrinsics take an alternative value just like llvm.masked.load and its passthru operand? You would get identical behavior to your proposal by setting this passthru to undef. | |
| llvm/docs/LangRef.rst | ||
|---|---|---|
| 18275 | My take is this: if there was a passthru parameter we'd still have to optimize/match the op+select into op_with_passthru. So, if the simple op+select idiom (that people are already using, btw) suffices to model passthru why add a redundant parameter/code path? We had this discussion a while back: https://reviews.llvm.org/D57504#1851456 | |
| llvm/docs/LangRef.rst | ||
|---|---|---|
| 18275 | Ah, I see. Fair enough :) | |
| llvm/docs/LangRef.rst | ||
|---|---|---|
| 18275 | Thanks for following up on your drive-by comment ;-) | |
| llvm/include/llvm/IR/IntrinsicInst.h | ||
|---|---|---|
| 401 ↗ | (On Diff #340529) | Should these be in D93455 so they aren't unused functions? | 
| 404 ↗ | (On Diff #340529) | These names should be lower case per coding standards. | 
| 406 ↗ | (On Diff #340529) | a exception -> an exception | 
| llvm/unittests/IR/VPIntrinsicTest.cpp | ||
| 22 | This looks duplicated | |
I realise this inherits from the documentation of the integer intrinsics, but I was wondering if this can be expressed as being equivalent to <%evl x float> in the following example. Would that be any clearer that the intrinsic is conceptually working on vectors of length %evl isn't actually executing the lanes above %evl (as in %t below)?