[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

[Lawerence, Peter via llvm-dev]

I think I have answered my own questions below, but now have additional questions,

I am now using :      let Constraints = "$src = $dst";       following examples from X86,
rather than TwoOperandAliasConstraint  that I had been following from Mips,
and I am now seeing TIED_TO in my  GenInstrInfo.inc  for the appropriate OperandInfo's,

but I am still seeing assembly code emitted that violates this constraint,

what else am I missing ?


thanks, Peter Lawrence.



the only thing I see that is out-of-the-ordinary in my GenInstrInfo.inc is
the OPERAND_MEMORY rather than OPERAND_REGISTER for my base-register operand
and OPERAND_MEMORY rather than OPERAND_IMMEDIATE for my offset operand,
but am still not sure how that happens or what to do to fix it ?

static const MCOperandInfo OperandInfo25[] = {
     { Xmc::AddrRegsRegClassID, 0, MCOI::OPERAND_REGISTER, 0 },
     { Xmc::AddrRegsRegClassID, 0, MCOI::OPERAND_MEMORY, ((0 << 16) | (1 << MCOI::TIED_TO)) },
     { -1, 0, MCOI::OPERAND_MEMORY, 0 }, };

I seem to be between a rock and a hard place:

let OperandType = "OPERAND_MEMORY" in {                           <----- I suspect my MEMORY_OPERAND comes from this
def memri     : Operand<iPTR> {
  let MIOperandInfo = (ops addrreg:$base, i16imm:$offset); }
}

def LEA : FMT_I6 <0x4c00, (outs addrreg:$dst), (ins memri:$addr), <----- I suspect the fix would be to split the memri
                                                                   ----- into separate reg and imm "ins" operands,
                "lea $dst, ${addr:arith}",
               [(set iPTR:$dst, addrri:$addr)]> {                 <----- but then I would not be able to write this pattern
                                                                   ----- and ISel would fail ?????
  let Constraints = "$addr.base = $dst";
  let isCodeGenOnly = 1;
}


-- Sleepless in Silicon Valley...



From: Lawerence, Peter
Sent: Monday, November 23, 2015 3:37 PM
To: 'llvm-dev at lists.llvm.org'
Subject: Qs about TwoOperandAliasConstraint and TIED_TO

in  llvm-3.6.2.src


1.   when I put this around one of my instruction definitions in my target "InstrInfo.td" file,

let TwoOperandAliasConstraint = "$dst = $rs1" in {
}

I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction,

the question is what am I doing wrong ?


---> you are doing nothing wrong, the same thing happens for Mips,
---> all its' ArithLogicR and ArithLogicI instructions have    let TwoOperandAliasConstraint = "$rd = $rs";
---> but if you look at MipsGenInstrInfo.inc
---> AND, OR, XOR, ADD, SUB, ADDu, SUBu, etc..., use OperandInfo14 does not contain any TIED_TO
---> ANDi, ORi, XORi, ADDi, SUBi, ADDui, SUBui, etc..., use OperandInfo29 does not contain any TIED_TO

---> there is probably a bug somewhere in utils/TableGen/

---> this is probably working for Mips in the case of ArithLogicR, since those instructions really are 3-operand
---> but it is mysterious how RA gets it right for the ArithLogicI case, since those instructions really are 2-operand

---> IMHO, from a Software Engineering point of view TwoOperandAliasConstraint should either be fixed or deleted,
---> currently it is misleading, and in a target-description that should be usable as a reference design
---> (as Mips can be viewed as the quintessential RISC instruction set),  at least I tried to use it as such.


2.    I've noticed that TwoOperandAliasConstraint does not appear anywhere in   source/lib/Target/X86/*

yet  TIED_TO occurs in 162 of the  OperandInfo's in   build/lib/Target/X86/X86GenInstrInfo.inc

the question is how does TIED_TO happen if not by  TwoOperandAliasConstraint  ?


---> searching X86InstrInfo.td and X86GenInstrInfo.inc it is seems that
--->     let Constraints = "$src = $dst";
---> gets recognized by TableGen and converted into a TIED_TO constraint


thanks, Peter Lawrence.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151124/5c3977b5/attachment-0001.html>