Getting MCInst "ins" and "outs"

Hi all.

I'm looking for some way to do code analysis with LLVM. Can someone please give me a hint, if it is possible to query an MCInst for what are input operands and what are output operands?

Small example.

Consider we have an instruction:
  str r1, [sp, #8]

Being mapped into MCInst instance it has the following operands:
  <MCOperand Reg:61> <-- maps to reg r1
  <MCOperand Reg:105> <-- maps to reg sp
  <MCOperand Imm:8> <-- maps to immed #8
  <MCOperand Imm:14>
  <MCOperand Reg:0>

Now, what are the two last operands (that are not actually present in disassembly)? And is it somehow possible to map the operands to OutOperandList/InOperandList found in the td definition?

Hi, so far as I know, we can not query whether or not an MCOperand is
input or output.
An MCInst is composed of two basic part: an opcode and an operand
list. We determine that an operand
is output or not. Usually output operands are placed before input
operands in the list.

When we define a instruction in tablegen, (outs ...) and (ins ...)
implies two things:
1. For MC layer, it defines how operand list is composed and operand
order in that list.
2. IO property for MachineInstr when we perform instruction selection
and other operations on MachineInstr.

So if you want to access IO property fo some operand, you can only get
it done when you are handling MachineInstr.

Any way, if you know which instruction a MCInst is and its operand
list, you DO know which of its operands are output or input "in your
mind", right?

Regards.

Hi, so far as I know, we can not query whether or not an MCOperand is
input or output.
An MCInst is composed of two basic part: an opcode and an operand
list. Usually output operands are placed before input operands in the
list.

When we define a instruction in tablegen, (outs ...) and (ins ...)
implies two things:
1. For MC layer, it defines how operand list is composed and operand
order in that list.
2. IO property for MachineInstr when we perform instruction selection
and other operations on MachineInstr.

So if you want to access IO property fo some operand, you can only get
it done when you are handling MachineInstr.

Any way, if you know which instruction a MCInst is and its operand
list, you DO know which of its operands are output or input "in your
mind", right?

Regards.

The MCInstrDesc has a method getNumDefs() which tells you how many 'out registers' that MCInst has. The 'out' registers are always at the beginning of the list. You can also use getNumOperands().

Not sure if this is what you are looking for.

Hi,

The MCInstrDesc has a method getNumDefs() which tells you how many 'out
registers' that MCInst has. The 'out' registers are always at the beginning
of the list. You can also use getNumOperands().

I've run into the problem, that this doesn't work for instructions which have
variadic arguments like Push and Pop on ARM/Thumb. There is currently no way
to tell if the registers beginning with getNumOperands()-2 are 'ins' or
'outs'.

Not sure if this is what you are looking for.

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] On
Behalf Of Vladimir Pouzanov Sent: Sunday, December 23, 2012 3:35 PM
To: llvmdev@cs.uiuc.edu
Subject: [LLVMdev] Getting MCInst "ins" and "outs"

[...]

Now, what are the two last operands (that are not actually present in
disassembly)? And is it somehow possible to map the operands to
OutOperandList/InOperandList found in the td definition?

I don't know about your specific case, but these are often flags (for
conditional execution, addressing specification etc.). They might show as
suffixes on the instruction name in the assembly.

It seems that I'm better off making a small per-instruction wrappers (as I really need a place to put a bunch of business logic anyway).

Thanks for your hints.

In this case Imm:14 is the condition code of the instruction; 14 is ARMCC::AL (always execute) and Reg:0 will normally show the input flags register, generally CPSR, if there is one (0 is NOREG). STR can't write flags, but for an instruction that can, there would be another reg listed after that which would be either CPSR or NOREG depending on the "S" bit of the instruction.

Hope that helps,
Gordon Keiser
Software Development Engineer
Arxan Technologies