-
Notifications
You must be signed in to change notification settings - Fork 15.5k
Open
Labels
discourseBugs or requests for LLVM DiscourseBugs or requests for LLVM Discoursellvm:codegenllvm:regallocquestionA question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!
Description
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
...
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
...
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
$z16for%82) — allocator logged the hint but still assigned%82to$z19.
Desired outcome
- Force/ensure that the 0th register of
FCVTZS_ZPmZ_StoS_UNDEFand the 0th register ofFRINTN_ZPmZ_UNDEF_Sare 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!
Metadata
Metadata
Assignees
Labels
discourseBugs or requests for LLVM DiscourseBugs or requests for LLVM Discoursellvm:codegenllvm:regallocquestionA question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!A question, not bug report. Check out https://llvm.org/docs/GettingInvolved.html instead!