[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

Wed Nov 25 01:00:10 PST 2015

----- Original Message -----

> From: "Peter via llvm-dev Lawerence" <llvm-dev at lists.llvm.org>
> To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> Sent: Wednesday, November 25, 2015 12:33:21 AM
> Subject: Re: [llvm-dev] Qs about TwoOperandAliasConstraint and
> TIED_TO

> I think I have answered my own question again,

> I will use a CustomInserter to create my own MachineInstruction for
> my LEA instruction,
> that way I can call BuildMI myself, and add whatever operands are
> needed,
> with whatever TiedTo information is needed.
That shouldn't be necessary. PowerPC, for example, uses tired register constraints on its pre-increment load/store instructions, and this works correctly. 

Also, as far as I can tell, nothing in CodeGen makes use of the OPERAND_REGISTER vs. OPERAND_MEMORY distinction. Those are provided for use by the targets when implementing their assembly parsing and printing. In fact, if you look at lib/Target/PowerPC/PPCGenInstrInfo.inc, a lot of the corresponding operands are tagged OPERAND_UNKNOWN (I should probably fix that, but that's another story). 

> I have looked into the register allocator’s
> “TwoOperandInstructionPass.cpp”,
> and it does not look up any information in the “XyzGenInstrInfo.inc”
> OperandInfo tables,
This is not the right place to look. Tied register operands are handled as part of the generic register allocation infrastructure TwoAddressInstructionPass is an additional set of optimizations implemented with the help of target callbacks (convertToThreeAddress, etc.). 

When you say that you're still seeing problems, can you be more specific? 

Also, you probably also want to add: 

let DisableEncoding = "$dst" 

to your definition. 

-Hal 

> rather CodeGen (or in my case my CustomInserter) puts the necessary
> info into the
> MachineOperand, and RA gets it from there.

> so the fact that the generated OperandInfo table has the wrong
> operand type
> (Memory, when Register is needed) won’t matter.

> -Peter Lawrence.

> From: Lawerence, Peter
> Sent: Tuesday, November 24, 2015 11:27 AM
> To: 'llvm-dev at lists.llvm.org'
> Subject: RE: Qs about TwoOperandAliasConstraint and TIED_TO

> 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.

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151125/a9589307/attachment.html>