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 | ||
---|---|---|
17384 | 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)? | |
17408 | addition -> subtraction | |
17422 | same here: addition and maybe add <i_fsub>? | |
17457 | addition -> multiplication | |
17471 | addition -> multiplication | |
17506 | addition -> division | |
17520 | same here | |
17555 | addition -> remainder | |
17569 | addition -> remainder | |
llvm/include/llvm/IR/VPIntrinsics.def | ||
162 | integer -> floating-point? |
llvm/docs/LangRef.rst | ||
---|---|---|
17384 | 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 | ||
---|---|---|
17387 | 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 | ||
---|---|---|
17387 | 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 | ||
---|---|---|
17387 | Ah, I see. Fair enough :) |
llvm/docs/LangRef.rst | ||
---|---|---|
17387 | Thanks for following up on your drive-by comment ;-) |
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)?