[PATCH] D102918: [RISCV] Avoid undef result due to promotion of FPOWI exponent

Fri May 21 09:08:18 PDT 2021

craig.topper added a comment.

In D102918#2773859 <https://reviews.llvm.org/D102918#2773859>, @craig.topper wrote:

> Ok I missed the other patches this is linked to. The RISCV64 ABI is to pass int as an i64 that has been sign extended which is what we were doing.
>
> So should we Custom type legalize to the exact sequence we were using before?

In D102918#2773961 <https://reviews.llvm.org/D102918#2773961>, @bjope wrote:

> In D102918#2773859 <https://reviews.llvm.org/D102918#2773859>, @craig.topper wrote:
>
>> Ok I missed the other patches this is linked to. The RISCV64 ABI is to pass int as an i64 that has been sign extended which is what we were doing.
>>
>> So should we Custom type legalize to the exact sequence we were using before?
>
> Since it is a bit fragile to allow the generic promotion to promote the exponenet to a type larger than "sizeof(int)" I was looking for some way to handle this special case for RISCV64 (as that is the only target I've found that uses the generic promotion to implement the calling convention ABI sign-extend).

It's quite likely the sign extend was added to LegalizeIntegerTypes specifically for RISCV.

> Before I uploaded this patch I made some attempts trying to implement this using some other hack. But I didn't feel confident with those hacks. Maybe I was hooking into the wrong place, but I guess one need to consider the soft floats (or not releveant for RISCV?) and strict fp (or not?) . And one still need to legalize the fp operand? And the result? So one would need to do all that using some custom lowering, right?

RISCV does have soft float. SoftenFloatRes_FPOWI probably ends up promoting the type when it goes through makeLibCall. So it be ok already?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102918/new/

https://reviews.llvm.org/D102918