[llvm-dev] Default Implementation for Pseudo Instructions

Dean Michael Berris via llvm-dev llvm-dev at lists.llvm.org
Mon May 16 21:00:38 PDT 2016

Hi LLVM-dev,

I'm working on XRay, and one of the parts of it is the introduction of a
couple of pseudo instructions -- one of which is PATCHABLE_RET, which wraps
a return instruction (similar to how PATCHABLE_OP works).

In http://reviews.llvm.org/D19904, I'm trying to find a way of making
PATCHABLE_RET have a default implementation in platforms where they're not
supported yet (i.e., not X86).

In my very limited research into this, I think I've narrowed it down to two

- SelectionDAGTargetInfo has some hooks for specific instructions to be
lowered/handled. A default implementation could be to just unpack the
operands from the PATCHABLE_* instructions. In particular I'm looking at
potentially adding some more functions to
for the PATCHABLE_* instructions, and finding where the SelectionDAG stuff
is invoked to special-case the PATCHABLE_* instructions.

- TargetLowering is another place where this might work. We can have
special dispatch for the PATCHABLE_* instructions there, and also where we
use a custom inserter. We can mark the instructions to use a custom
inserter, have some overridable hooks in TargetLowering which by default
just unpacks the operands into new MachineInstr instances, then override
those in X86's specific lowering. Requisite link:

Some questions:

1) Is this even something I need to worry about? Since PATCHABLE_RET is
being inserted by a late MachineFunctionPass, it could just do this for a
white-listed set of platforms. This seems not ideal.

2) Machine IR (mir) seems to be where PATCHABLE_RET might show up, and may
need to be hand-crafted. Are the above two places the right places where
these instructions could be intercepted, or am I missing something more

Thanks in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160517/1b1ac004/attachment.html>

More information about the llvm-dev mailing list