[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