[PATCH] D118020: [RISCV] Set CostPerUse for floating point registers

Wang Pengcheng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 25 23:09:24 PST 2022


pcwang-thead added a comment.

In D118020#3265955 <https://reviews.llvm.org/D118020#3265955>, @pcwang-thead wrote:

> In D118020#3265940 <https://reviews.llvm.org/D118020#3265940>, @asb wrote:
>
>> This is causing multiple compiler-time failures (assertions) for me on the GCC torture suite. e.g. 930608-1.c for rv32imafdc with the ilp32 ABI at O{1,2,3,s}. pr44942.c fails similarly for rv32imafdc with the ilp32d ABI at O{1,2,3,s}. It seems likely it's unmasking a bug elsewhere, though I haven't done any more delving.
>
> That's weird, I will have a look.
>
> Thanks.

I may have fixed this bug (these two GCC torture tests are OK at least ) in D118124 <https://reviews.llvm.org/D118124>.

But I have the same question as MatzeB said, why will it generate such code?

For example, `f` in `930608-1.c` only contains one return instruction with GCC for RISCV or clang for ARM/AArch64 target:

  double f (double a) {}
  f:
  	ret

And below is what we have now:

  f: 
  	addi	sp, sp, -16
  	fsd	fs1, 8(sp)
  	lw	a0, 8(sp)
  	lw	a1, 12(sp)
  	addi	sp, sp, 16
  	ret

In the MIR level, we can eliminate `IMPLICIT_DEF`s after `processimpdefs` pass:

  bb.0.entry:
    %4:fpr64 = IMPLICIT_DEF                                             # Eliminated
    FSD killed %4:fpr64, %stack.0, 0 :: (store (s64) into %stack.0)     # -> FSD killed undef %4:fpr64, %stack.0, 0 :: (store (s64) into %stack.0)
    %2:gpr = LW %stack.0, 0 :: (load (s32) from %stack.0, align 8)
    %3:gpr = LW %stack.0, 4 :: (load (s32) from %stack.0 + 4, basealign 8)
    $x10 = COPY %2:gpr
    $x11 = COPY %3:gpr
    PseudoRET implicit $x10, implicit $x11

But we can't eliminate these dead stores.

I guess there may have some problems in handling `BuildPairF64` and `SplitF64`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118020



More information about the llvm-commits mailing list