Move MCSymbolRefExpr::VK_AMDGPU_ to AMDGPUMCExpr::

[MaskRay]

MCSymbolRefExpr::VariantKind isn't ideal for encoding relocation operators because:

• other expressions, like MCConstantExpr (e.g., PPC 4@l) and MCBinaryExpr (e.g., PPC (a+1)@l), also need it
• semantics become unclear (e.g., folding expressions with @).
• The generic interface MCSymbolRefExpr offers no target-specific extension point. Any target-specific logic will pollute the generic interface.

MCTargetExpr subclasses, as used by AArch64 and RISC-V, offer a cleaner approach.
(MIPS, while also uses MCTargetExpr, has significant tech debt.)
Ideally, limit MCTargetExpr to top-level use to encode one single relocation and avoid its inclusion as a subexpression.

AMDMCExpr::VariantKind is already present. Should just move more VK_AMDGPU_* there. @arsenm

Similar issue for VE: #130003

---

AArch64 is a good model where the VariantKind information is incoded as AArch64MCExpr (derived from MCTargetExpr)

// llvm/lib/Target/AArch64/AArch64MCInstLower.cpp
  Expr = AArch64MCExpr::create(Expr, RefKind, Ctx);
// llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
ImmVal = AArch64MCExpr::create(ImmVal, RefKind, getContext());

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

Author: Fangrui Song (MaskRay)

`MCSymbolRefExpr::VariantKind` isn't ideal for encoding relocation operators because:

• other expressions, like MCConstantExpr (e.g., PPC 4@<!-- -->l) and MCBinaryExpr (e.g., PPC (a+1)@<!-- -->l), also need it
• semantics become unclear (e.g., folding expressions with @).
• The generic interface MCSymbolRefExpr offers no target-specific extension point. Any target-specific logic will pollute the generic interface.

MCTargetExpr subclasses, as used by AArch64 and RISC-V, offer a cleaner approach.
(MIPS, while also uses MCTargetExpr, has significant tech debt.)
Ideally, limit MCTargetExpr to top-level use to encode one single relocation and avoid its inclusion as a subexpression.

AMDMCExpr::VariantKind is already present. Should just move more VK_AMDGPU_* there. @arsenm

Similar issue for VE: #130003

---

AArch64 is a good model where the VariantKind information is incoded as AArch64MCExpr (derived from MCTargetExpr)

// llvm/lib/Target/AArch64/AArch64MCInstLower.cpp
  Expr = AArch64MCExpr::create(Expr, RefKind, Ctx);
// llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
ImmVal = AArch64MCExpr::create(ImmVal, RefKind, getContext());

[arsenm]

I think we shouldn't need any of those relocations in the first place. They duplicate generic relocations, and the only difference is splitting the high and low halves of the final 64-bit address. I think these should be replaced with some kind of expression to extract the low and high bits, but I'm not sure how those work

[MaskRay]

There is no such a thing called a "generic relocation". All MCSymbolRefExpr::VariantKind should go away and MCSymbolRefExpr is not an appropriate place to place relocations (think of MCConstantExpr, MCBinaryExpr).