| Issue |
130003
|
| Summary |
[VE] Move MCSymbolRefExpr::VK_VE_ to VEMCExpr::
|
| Labels |
backend:VE
|
| Assignees |
|
| Reporter |
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 `@`).
`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.
The VE target added `MCSymbolRefExpr::VariantKind::VK_VE_` in 2020 (https://reviews.llvm.org/D83170).
I worry that new targets would follow suit and add inappropriate `VK_*` to the list...
---
VE should migrate to follow AArch64 where the `VariantKind` information is incoded as `AArch64MCExpr` (derived from `MCTargetExpr`), different from most other targets.
```
// 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());
```
@kaz7 @simoll
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
