[llvm-dev] Is there a way to correlate operation to machine instruction?
Matt Arsenault via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 12 10:36:51 PDT 2017
On 04/12/2017 10:25 AM, Ryan Taylor via llvm-dev wrote:
> 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
> Currently, I'm simply building a new machine instruction via BuildMI
> with the appropriate operands and then removing the old machine
> 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).
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev