[llvm-dev] Is there a way to correlate operation to machine instruction?

[Ryan Taylor via llvm-dev]

Matt,

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

Thanks.

On Wed, Apr 12, 2017 at 1:36 PM, Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> 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 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).
>
> Thanks.
>
>
> _______________________________________________
> 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.
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/0766b7d4/attachment.html>