thr3ads.net - llvm dev - [llvm-dev] Qs about TwoOperandAliasConstraint and TIED

If this information is useful, please help other people find it:
Share via:

Lawerence, Peter via llvm-dev

2015-Nov-23 23:36 UTC

[llvm-dev] 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 ?



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  ?



thanks, Peter Lawrence.

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

Lawerence, Peter via llvm-dev

2015-Nov-24 19:26 UTC

head link

[llvm-dev] 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.

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

Lawerence, Peter via llvm-dev

2015-Nov-25 06:33 UTC

head link

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

I have looked into the register allocator's
"TwoOperandInstructionPass.cpp",
and it does not look up any information in the "XyzGenInstrInfo.inc"
OperandInfo tables,
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151125/8003536d/attachment-0001.html>

Daniel Sanders via llvm-dev

2015-Nov-26 10:03 UTC

head link

[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

> 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 ?
TwoOperandAliasConstraint is about assembly matching rather than instruction
selection. If you have an instruction of the form:
                addu $dst, $rs1, $rs2
and set TwoOperandAliasConstraint to "$dst = $rs1", then the assembly
matcher will accept both of these:
                addu $dst, $rs1, $rs2
                addu $dst, $rs2
with the latter being expanded to:
                addu $dst, $dst, $rs2.

As you've found, 'Constraints' is the right place to say that $rs1
and $dst must always be the same register.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
Lawerence, Peter via llvm-dev
Sent: 24 November 2015 19:27
To: 'llvm-dev at lists.llvm.org'
Subject: Re: [llvm-dev] 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151126/21085492/attachment.html>

Possibly Parallel Threads

Search for more possibly parallel threads

llvm dev - Nov 2015 - Qs about TwoOperandAliasConstraint and TIED_TO

[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

[llvm-dev] Qs about TwoOperandAliasConstraint and TIED_TO

Possibly Parallel Threads