[llvm] [AArch64][GISel] Assign registers into FPR if they feed into FP instructions indirectly via PHI (PR #94618)

via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 7 01:54:02 PDT 2024


Him188 wrote:

> Maybe `case TargetOpcode::G_LOAD: `needs some special treatment for phis.

Yes, we can recursively visit phis which is what this PR is doing. `onlyUsesFP` calls `hasFPConstraints`. I modified `hasFPConstraints` to consider this. 

> Do you really need the flag. 

Humm... The flag gives more confidence about the FP usage. Without the flag, we have to rely on the usages of phi and guess whether it feeds FP. 

1. If we assign `%1` to FPR if there is any FP usage, it works with s3110. Note that by recursively looking into PHI, we have significantly increased the opportunity to locate FP usages. It's more likely for a LOAD to be assigned FPR. This might generate more copies if most of the usage is in GPR.

2. If we assign `%1` to FPR only if all usages are FP, there will be no false positives. But this is too strict. It can not even fix the simplified s3110.

An example of potential breaking change with the first strategy is `int_load_phi`:
```
  bb.0:
    liveins: $w0
    successors: %bb.1
    %0:_(s32) = COPY $w0
    %1:_(p0) = G_GLOBAL_VALUE @var_fp
  ; CHECK-NEXT:   %fp_load:gpr(s32) = G_LOAD [[GV]](p0) :: (load (s32) from @var_int)
    %fp_load:_(s32) = G_LOAD %1 :: (load 4 from @var_int)

  bb.1:
    successors: %bb.1, %bb.2
  ; CHECK-NEXT:   [[PHI:%[0-9]+]]:gpr(s32) = PHI %fp_load(s32), %bb.0, [[PHI]](s32), %bb.1
    %2:_(s32) = PHI %fp_load, %bb.0, %2, %bb.1
    G_BRCOND %0, %bb.1

  bb.2:
    $s0 = COPY %2
    RET_ReallyLR implicit $s0
```

`$s0 = COPY %2` has FP constraint, so PHI is considered feeding FP, and then `%fp_load` is assigned FPR instead of GPR. 
It doesn't seem to be a regression in this small test but I suspect it might perform worse in a larger program.

We might need the GLOBAL mode in the future to properly fix this. 

But I agree with @arsenm that adding a flag just for this might not be good. 


https://github.com/llvm/llvm-project/pull/94618


More information about the llvm-commits mailing list