| Issue |
171127
|
| Summary |
[SVE]Register allocation hint ignored
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
MaooJian
|
Environment
* LLVM version: llvm15
* Compiler options: `-O2 -march=armv8.2-a+sve`
Problem summary
I want the `FCVTZS_ZPmZ_StoS_UNDEF` instruction's 0th register and the `FRINTN_ZPmZ_UNDEF_S` instruction's 0th register to be assigned the same physical Z register. I tried providing a register hint, and the allocator considered the hint but the final allocation still placed them into different physical registers.
IR Dump Before Virtual Register Rewriter
```asm
...
3600B %56:zpr = LD1W %13:ppr_3b, %54:gpr64common, %233:gpr64common :: (dereferenceable invariant load unknown-size from %ir.uglygep, align 16, !tbaa !16)
3616B %58:zpr = LD1W %13:ppr_3b, %57:gpr64common, %233:gpr64common :: (dereferenceable invariant load unknown-size from %ir.uglygep83, align 16, !tbaa !16)
3632B %61:zpr = FMUL_ZZZ_S killed %56:zpr, %60:zpr
3648B %62:zpr = FRINTN_ZPmZ_UNDEF_S undef %63:zpr, %13:ppr_3b, killed %61:zpr
3664B %82:zpr = FCVTZS_ZPmZ_StoS_UNDEF undef %65:zpr, %13:ppr_3b, killed %62:zpr
3680B %66:zpr = FMUL_ZZZ_S killed %58:zpr, %60:zpr
3728B %73:zpr = COPY %82:zpr
3808B %82:zpr = ASR_ZPmI_S %13:ppr_3b, killed %82:zpr(tied-def 0), 11
3812B %67:zpr = FRINTN_ZPmZ_UNDEF_S undef %68:zpr, %13:ppr_3b, killed %66:zpr
3816B %87:zpr = FCVTZS_ZPmZ_StoS_UNDEF undef %70:zpr, %13:ppr_3b, killed %67:zpr
3856B %80:zpr = COPY %82:zpr
3860B %74:zpr = COPY %87:zpr
...
```
IR Dump After Virtual Register Rewriter
```asm
...
3600B renamable $z16 = LD1W renamable $p0, renamable $x9, renamable $x8 :: (dereferenceable invariant load unknown-size from %ir.uglygep, align 16, !tbaa !16)
3616B renamable $z17 = LD1W renamable $p0, renamable $x10, renamable $x8 :: (dereferenceable invariant load unknown-size from %ir.uglygep83, align 16, !tbaa !16)
3632B renamable $z16 = FMUL_ZZZ_S killed renamable $z16, renamable $z0
3648B renamable $z16 = FRINTN_ZPmZ_UNDEF_S undef renamable $z0, renamable $p0, killed renamable $z16
3664B renamable $z19 = FCVTZS_ZPmZ_StoS_UNDEF undef renamable $z0, renamable $p0, killed renamable $z16
3680B renamable $z17 = FMUL_ZZZ_S killed renamable $z17, renamable $z0
3728B renamable $z16 = COPY renamable $z19
3808B renamable $z19 = ASR_ZPmI_S renamable $p0, killed renamable $z19(tied-def 0), 11
3812B renamable $z17 = FRINTN_ZPmZ_UNDEF_S undef renamable $z0, renamable $p0, killed renamable $z17
3816B renamable $z18 = FCVTZS_ZPmZ_StoS_UNDEF undef renamable $z0, renamable $p0, killed renamable $z17
3856B renamable $z20 = COPY renamable $z19
3860B renamable $z17 = COPY renamable $z18
...
```
Allocator debug excerpts showing hints were present but ignored
```
...
selectOrSplit ZPR:%62 [3648r,3664r:0) 0@3648r weight:INF w=INF
assigning %62 to $z16: B16 [3648r,3664r:0) 0@3648r Z16_HI [3648r,3664r:0) 0@3648r
selectOrSplit ZPR:%82 [3664r,3808r:2)[3808r,3936r:0)[3936r,4020r:1)[4020r,4032r:3)[4032r,4344r:4)[4344r,4464r:5)[4464r,4512r:6) 0@3808r 1@3936r 2@3664r 3@4020r 4@4032r 5@4344r 6@4464r weight:2.977558e-01 w=2.977558e-01
hints: $z16
assigning %82 to $z19: B19 [3664r,3808r:2)[3808r,3936r:0)[3936r,4020r:1)[4020r,4032r:3)[4032r,4344r:4)[4344r,4464r:5)[4464r,4512r:6) 0@3808r 1@3936r 2@3664r 3@4020r 4@4032r 5@4344r 6@4464r Z19_HI [3664r,3808r:2)[3808r,3936r:0)[3936r,4020r:1)[4020r,4032r:3)[4032r,4344r:4)[4344r,4464r:5)[4464r,4512r:6) 0@3808r 1@3936r 2@3664r 3@4020r 4@4032r 5@4344r 6@4464r
...
```
What I tried
* Added a register hint (to prefer `$z16` for `%82`) — allocator logged the hint but still assigned `%82` to `$z19`.
Desired outcome
* Force/ensure that the 0th register of `FCVTZS_ZPmZ_StoS_UNDEF` and the 0th register of `FRINTN_ZPmZ_UNDEF_S` are assigned the same physical Z register.
Questions / request for help
* Is there a reliable way to force two virtual ZPR register values to be assigned the same physical Z register in LLVM's register allocator for SVE targets? Are there known allocator limitations or interactions that prevent the allocator from honoring such hints in this pattern?
Thanks in advance for any suggestions or pointers!
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs