AArch64InstrInfo::getInstSizeInBytes does not take XRay instrumentation opcodes into account.
The default case of this function unconditionally returns 4, except for size definitions specified by TableGen.
However, on AArch64, the XRay pseudo-instructions expand to 32 bytes.
Since the XRay pseudo-opcodes are target-independent, the TableGen path doesn't get hit and therefore the size returned is wrong.
Details
- Reviewers
- None
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Okay, taking this off the review queue until I take a look at the other bug incidentally exposed by fixing this one; the MachineOutliner doesn't properly adjust attributes of new outlined functions with XRay instrumentation opcodes. (should it even run on those at all?)
As such, what happens is that this check doesn't pass, meaning CurrentFnBegin isn't set, meaning that an assertion failure is thrown when the code generator tries to use it as a symbol when emitting the XRay instrumentation table.
The reason this testcase didn't fail before is because AArch64InstrInfo::getOutliningCandidateInfo uses the sizes of instructions as part of the outlining heuristic. When the pseudo-opcode sizes were fixed, the heuristic decided it was profitable to outline an XRay pseudo-instruction, triggering the bug.