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

[Matt Arsenault via llvm-dev]

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 list
> llvm-dev at lists.llvm.org
> http://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/528ed349/attachment.html>