Displaying 3 results from an estimated 3 matches for "opcval".
Did you mean:
op2val
2007 Apr 18
2
[LLVMdev] CodeEmitterGen
...up
MI operand number by name, rather than assuming the order of
declarations matches the order of the operands. This way tablegen can
emit an error if the field name and operand name fail to match rather
than silently producing an incorrect GenCodeEmitter.
class MyFormat<bits<32> OpcVal, dag ops, string asmstr, list<dag>
pattern, InstrItinClass itin> :
MyInst<ops, asmstr, pattern, itin> {
let Inst{31-28} = OpcVal{31-28};
bits<6> Rsrc1; <===== Because destination is required first in
operand ordering,
bits<6> Rdest; <=====...
2007 Apr 18
0
[LLVMdev] CodeEmitterGen
On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote:
> I noticed that the TableGen code emitter generator assumes that the
> instruction fields are declared in the instruction format in the
> same order that operands are defined. This seems like a bad
> dependence to me, and that TableGen should match the name of field
> declared in the instruction with the name of the
2007 Apr 18
2
[LLVMdev] CodeEmitterGen
I noticed that the TableGen code emitter generator assumes that the
instruction fields are declared in the instruction format in the same
order that operands are defined. This seems like a bad dependence to
me, and that TableGen should match the name of field declared in the
instruction with the name of the operand in order to determine which
operand of the MI to use
.
See