Is there a way to correlate operation to machine instruction?

For example, given a multiclass for ADD 32 bit that might produce something like:

ADD32_REG_REG_REG (operands are all registers for a 32 bit add)
ADD32_REG_IMM_REG (srcA is a register, srcB is an immediate and dst is a register)
ADD32_REG_IMM_MEM (srcA is a register, srcB is an immediate and dst is a memory address)

What I’d like to do is replace an operand, for example, change srcA from a REG to a MEM in ADD32_REG_REG_REG (so it would be ADD32_MEM_REG_REG).

Currently, I’m simply building a new machine instruction via BuildMI with the appropriate operands and then removing the old machine instruction.

My problem comes in trying to correlate the operation given the old instruction to the new instruction. How can I tell the old instruction was an ADD32?

The problem I’m trying to solve is the DAG is CSE’d, which is generating extra move instructions (memory into register) when the memory is used more than once, this is unnecessary for us. Would it be possible to change the DAG right before Instruction Selection (this would be much easier than doing it in the backend but when I’ve tried in the past, CSE is performed always).


I would recommend not having separate instruction definitions for every permutation of register and immediate operands, although I realize this is what most targets seem to do. Then you can simply replace the operand of the instruction rather than having to figure out the new opcode you need to use. What AMDGPU does is define various RegisterOperands with custom types that are allowed by the verifier to contain immediates. The same principle should also work for mem operands. You could also try to define an InstrMapping to get the other versions of the opcode.



so in AMDGPU, the operands are sort of ‘generic’? Can you point me to the right places?


Not exactly generic, but they have custom defined constraints. Look at the definitions for the VSrc_* operand types in These set the OperandType on the Operand to a custom enum, and the target verifyInstruction checks the custom constraints.


Is it possible to insert duplicate SDNodes prior to ISel (preferably during and directly before selection) that won’t be CSE’d out?