search for: op1reg

...or is about. I recommend taking a look at the getReg(*) methods in the X86 instruction selector. The basic code generation stage for an add, boiled down to its simplest form, basically looks like this: void visitAdd(BinaryOperator &B) { unsigned Op0Reg = getReg(B.getOperand(0)); unsigned Op1Reg = getReg(B.getOperand(1)); unsigned DestReg = getReg(B); unsigned Opcode = (get the opcode for the size of the add); BuildMI(<where>, Opcode, 2, DestReg).addReg(Op0Reg).addReg(Op1Reg); } The nice thing about the "getReg" functionality is that it is a member of the instructio...

Ok, I'm now trying to write instruction selector and have some questions 1. The MachineInstrBuilder has methods to add register operand and immediate operand. However, what would be really nice is a method to add Value*. So, I would write: BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); and depending on whether the passed Value* is contant or instruction, the add

...ing a look at the getReg(*) methods in the X86 instruction > selector. The basic code generation stage for an add, boiled down to its > simplest form, basically looks like this: > > void visitAdd(BinaryOperator &B) { > unsigned Op0Reg = getReg(B.getOperand(0)); > unsigned Op1Reg = getReg(B.getOperand(1)); > unsigned DestReg = getReg(B); > > unsigned Opcode = (get the opcode for the size of the add); > BuildMI(<where>, Opcode, 2, DestReg).addReg(Op0Reg).addReg(Op1Reg); > } > > The nice thing about the "getReg" functionality is that...

...whatever always goes to or1, or an in general irX + whatever goes to orX). AFAIK, InstrInfo.td only allow "$src = $dst" type constraints. Is it possible to describe more complex src/dst relations, like the one I need? Also, I have tried making say or1 and ir1 parts of a single superreg (op1reg), using "$src = $dst" and a pattern to wrap the operations with EXTRACT_SUBREG/INSERT_SUBREG compounds. But in that case I have two problems: 1) the LLVM op operates over a vector reg, thus *overwrites* the input also (and that is not what our machine does) 2) LLVM needs to be able to cop...