AMDGPU/MC: Try harder to evaluate absolute MC expressions #145146
Conversation
This is a follow-up to commit 24c8605 ("AMDGPU/MC: Fix emitting absolute expressions (llvm#136789)"). In some downstream work, we end up with an MCTargetExpr that is a maximum (AGVK_Max) in an instruction operand. getMachineOpValueCommon recognizes the absolute nature of the expression and doesn't emit a fixup. getLitEncoding needs to be aligned with this decision, else we end up with a 0 immediate without a corresponding fixup. Note that evaluateAsAbsolute checks for MCConstantExpr as a fast path, so this accepts strictly more cases than before. I've tried several ways to write a test for this without success. The challenge is that there is no upstream way to generate this kind of expression in an instruction operand natively, and trying to create one via inline assembly fails because the assembly parser evaluates the expression to a constant during parsing.
|
@llvm/pr-subscribers-backend-amdgpu Author: Nicolai Hähnle (nhaehnle) ChangesThis is a follow-up to commit 24c8605 ("AMDGPU/MC: Fix emitting absolute expressions (#136789)"). In some downstream work, we end up with an MCTargetExpr that is a maximum (AGVK_Max) in an instruction operand. getMachineOpValueCommon recognizes the absolute nature of the expression and doesn't emit a fixup. getLitEncoding needs to be aligned with this decision, else we end up with a 0 immediate without a corresponding fixup. Note that evaluateAsAbsolute checks for MCConstantExpr as a fast path, so this accepts strictly more cases than before. I've tried several ways to write a test for this without success. The challenge is that there is no upstream way to generate this kind of expression in an instruction operand natively, and trying to create one via inline assembly fails because the assembly parser evaluates the expression to a constant during parsing. Full diff: https://github.com/llvm/llvm-project/pull/145146.diff 1 Files Affected:
diff --git a/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCCodeEmitter.cpp b/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCCodeEmitter.cpp
index ab7e51ac28322..abb5003f3320b 100644
--- a/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCCodeEmitter.cpp
+++ b/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCCodeEmitter.cpp
@@ -255,13 +255,9 @@ AMDGPUMCCodeEmitter::getLitEncoding(const MCOperand &MO,
const MCSubtargetInfo &STI) const {
int64_t Imm;
if (MO.isExpr()) {
- const auto *C = dyn_cast<MCConstantExpr>(MO.getExpr());
- if (!C)
+ if (!MO.getExpr()->evaluateAsAbsolute(Imm))
return 255;
-
- Imm = C->getValue();
} else {
-
assert(!MO.isDFPImm());
if (!MO.isImm())
|
3 participants
This is a follow-up to commit 24c8605 ("AMDGPU/MC: Fix emitting absolute expressions (#136789)").
In some downstream work, we end up with an MCTargetExpr that is a maximum (AGVK_Max) in an instruction operand. getMachineOpValueCommon recognizes the absolute nature of the expression and doesn't emit a fixup. getLitEncoding needs to be aligned with this decision, else we end up with a 0 immediate without a corresponding fixup.
Note that evaluateAsAbsolute checks for MCConstantExpr as a fast path, so this accepts strictly more cases than before.
I've tried several ways to write a test for this without success. The challenge is that there is no upstream way to generate this kind of expression in an instruction operand natively, and trying to create one via inline assembly fails because the assembly parser evaluates the expression to a constant during parsing.