[llvm-dev] Is there a way to correlate operation to machine instruction?
Ryan Taylor via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 12 11:07:21 PDT 2017
so in AMDGPU, the operands are sort of 'generic'? Can you point me to the
On Wed, Apr 12, 2017 at 1:36 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
> 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
> 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
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 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