[PATCH] D104237: [RISCV][VP] Lower FP VP ISD nodes to RVV instructions
Craig Topper via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 15 11:58:50 PDT 2021
craig.topper added a comment.
In D104237#2819820 <https://reviews.llvm.org/D104237#2819820>, @frasercrmck wrote:
> In D104237#2818945 <https://reviews.llvm.org/D104237#2818945>, @rogfer01 wrote:
>
>> In D104237#2817214 <https://reviews.llvm.org/D104237#2817214>, @craig.topper wrote:
>>
>>> Will frem need to be expanded to a loop in the expansion pass?
>>
>> Would it be reasonable to expand it using the definition of `fmod` but vector-wise? It seems we'd need a division, a rounding to integer towards zero, convert back to float, a mutiplication and then a subtraction.
I don't think that gives an exact answer for all inputs since each of the individual operations can be subject to rounding.
> I think the VP expansion pass should probably be left to expand `vp.frem` to regular vector `frem` since that's a legal target-independent instruction and `ExpandVectorPredication` is meant to be generic.
>
> As for RISC-V I'm not sure. We could have our own expansion pass but I'd rather lower it to some sequence during ISel if we can. I'll take a look at `fmod` - I'm unsure if there needs to be additional logic for NaNs and all that fun.
Many targets scalarize frem on fixed vectors. It looks like frem on scalable vectors currently crashes on SVE because the type legalizer can't unroll it.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104237/new/
https://reviews.llvm.org/D104237
More information about the llvm-commits
mailing list