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
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)?