Glue two instructions together


for DAG-to-DAG instruction selection I’ve implemented a pattern, which creates from one SDNode two instructions, something like:

def: Pat<(NEW_SDNODE REG:$r1),


where INST_IN doesn’t accepts any inputs and INST_OUT accepts two inputs - one returned by INST_IN and REG;$r1.

Is there any possibility to ‘Glue’ two instruction created in a such way? Maybe something similar to creation SDNodes with SDNPOutGlue, SDNPInGlue) ?

These two instructions INST_IN and INST_OUT have to be one after another without any other inserted between them.



Create a pseudo-instruction that represents these two, and expand it into the actual instructions late, after optimizations.

I have one more question regarding expanding pseudo instruction.

These two Machine Instructions, which I mentioned earlier, have to be one after another, but also have to ‘communicate’ using any General Purpose Register

For example:

gpr4 INST_IN

r2 INST_OUT gpr4, r1

Is there any possibility to indicate that pseudo instruction, which is representing these two instruction,
will define and use ‘internally’ one additional register from ‘gpr’ pool (except those which are ins and outs).

Aa ‘internal’ register there might be use any of the register from ‘gpr’ pool. I wouldn’t like to indicate particular one.

Expanding will occur after register allocation, so the only solution I see is involving register scavenger during expanding pass.
Is usage register scavenger in such case is proper or maybe there is also any simpler approach?


You could hardcode a register for the pseudo instruction to use in the td file.
The register allocator will make sure not to clobber it.

let uses = [ R1 ], defs = [ R1 ] in {
def MYINST : Pseudo<>

Can you just have the pseudo instruction produce two values with one not connected to anything outside. I would think the register allocator should pick a register for it. Then you can just use the register when you expand it.


Thanks for your suggestion!
I didn’t want to hardcore particular one register, like R1.
So the approach with one additional output register could help resolve my issue