llvm dev - Apr 2017 - Is there a way to correlate operation to machine instruction?

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>

On 04/12/2017 11:07 AM, Ryan Taylor wrote:
> Matt,
>
>   so in AMDGPU, the operands are sort of 'generic'? Can you point
me
> to the right places?
>
> Thanks.
Not exactly generic, but they have custom defined constraints. Look at 
the definitions for the VSrc_* operand types in SIRegisterIno.td. These 
set the OperandType on the Operand to a custom enum, and the target 
verifyInstruction checks the custom constraints.

-Matt

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

Thanks.

On Wed, Apr 12, 2017 at 2:24 PM, Matt Arsenault <Matthew.Arsenault at
amd.com>
wrote:
> On 04/12/2017 11:07 AM, Ryan Taylor wrote:
>
>> Matt,
>>
>>   so in AMDGPU, the operands are sort of 'generic'? Can you
point me to
>> the right places?
>>
>> Thanks.
>>
> Not exactly generic, but they have custom defined constraints. Look at the
> definitions for the VSrc_* operand types in SIRegisterIno.td. These set the
> OperandType on the Operand to a custom enum, and the target
> verifyInstruction checks the custom constraints.
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170414/7a9db398/attachment.html>