The INLINEASM MIR instructions use immediate operands to encode the values of some operands.
The MachineInstr pretty printer function already handles those operands and prints human readable annotations instead of the immediates. This patch adds similar annotations to the output of the MIRPrinter, however uses the new MIROperandComment feature.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I've thought about adding enum to string conversion functions to InlineAsm.h, which could be reused from both MachineInstr.cpp and TargetInstrInfo.cpp to avoid code duplication.
Would that be preferred here?
I like it!
Some minor comments and nits in line.
llvm/lib/CodeGen/TargetInstrInfo.cpp | ||
---|---|---|
1330 | Can we do an early exit here: if (!MI.isInlineAsm()) return std::string(); that also reduces some identation below.. | |
1332 | do we need OS here? | |
1338 | can we then just do return "sideeffect"; here, and similar for the if-stmts below? | |
1353 | We don't need the 'else'? | |
1369 | probably just an assert here is better? | |
1404 | and same here? | |
llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp | ||
498–508 | This comment is out of date now and needs a minor update. |
llvm/lib/CodeGen/TargetInstrInfo.cpp | ||
---|---|---|
1332 | We could simply append to a std::string here, but the cases below need to append other things (integers), so I felt like using an ostream might be more elegant? | |
1338 | Unfortunately no, the immediate we are looking at here encodes multiple values at once, so we need to compose the string here. |
llvm/lib/CodeGen/TargetInstrInfo.cpp | ||
---|---|---|
1326 | Should this write to a raw_ostream rather than returning a string? |
llvm/lib/CodeGen/TargetInstrInfo.cpp | ||
---|---|---|
1326 | I'm not sure why it originally returned a string, but the function already existed before this patch |
llvm/test/CodeGen/X86/stack-folding-fp-nofpexcept.mir | ||
---|---|---|
41 | So if the register class encodings in the tablegen generated files have changed since the test was created, the input MIR is incorrect and the output will just show whatever class has that encoding today? And will suddently fail the next time the encodings change? |
llvm/test/CodeGen/X86/stack-folding-fp-nofpexcept.mir | ||
---|---|---|
41 | Yes, the register class is encoded in the "flags" immediate operand (7405578 in this case). If that encoding changes, this test needs to be updated. The change made here simply adds a human-readable comment to the immediate operands. The intent is to make tests more meaningful for humans to read. |
llvm_unreachable