thr3ads.net - llvm dev - [LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc [Apr 2014]

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

hilbert Wang

2014-Apr-26 05:20 UTC

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

hi Tim,guys,

 it was regarding  splitting 16-bit ADDC to two 8-bit ADDC+ADDE.

the 8-bit ADDE instruction is defined as:


let Constraints="$dst=$op0",mayStore=1,
hasSideEffects=0,neverHasSideEffects=1 in

def ADDErm: myInstr
<0x0,
(outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1),
"",
[set IntRegs:$dest (adde IntRegs:$op0, (load
ADDRi:$op1))]>
very unlucky, this instruction failed.

in the generated match table, there was flag OPFL_Chain.

it caused a token factor node to be created in  switch case
OPC_EmitMergeInputChains in SelectCodeCommon.

very bad, all uses of  input chain was replaced with ADDErm  Node.

so the created token factor node depends on the ADDErm node  after the
replacement.


very bad the ADDCrm node depends on above token factor.

because of the glue, a cycle formed. ADDE-->ADDC-->TF-->ADDE.


after I removed the flag OPFL_Chain in the match table, the problem was
gone.


So, my question was obvious:how could I make the table gen tool  not add
the said flag?




thanks

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

Tim Northover

2014-Apr-26 07:17 UTC

head link

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

Hi Hilbert,
> let Constraints="$dst=$op0",mayStore=1,
Are you sure you mean "mayStore" here and not "mayLoad"?
> very bad, all uses of  input chain was replaced with ADDErm  Node.
Since your ADDErm is also a load, it is going to need an input chain
of some kind (and hence OPFL_Chain) so that's not surprising on its
own.
> so the created token factor node depends on the ADDErm node  after the
> replacement.
I don't suppose you could post the output of "-view-isel-dags"
&
"-view-sched-dags"? I've got some ideas on how to reproduce what
you're seeing, but I need the exact DAGs to have much chance.

It sounds like it *might* be a bug in HandleMergeInputChains, if it
doesn't take glue into account somehow.

Cheers.

Tim.

hilbert Wang

2014-Apr-28 03:58 UTC

head link

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

guys,

1)i made a mistake in my post.
the said TF node was created when Selected() was called in ADDC node.


2) the source  code under test

short a,b;
void test()
{
a+=b;
}

3)the DAG after ADDC was seleced:
Select node:
0x4977a20: ch,glue = <<Unknown Machine Node #65419>> 0x4972bd0,
0x49731d0,
0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)>
Result node:
0x4977a20: ch,glue = <<Unknown Machine Node #65419>> 0x4972bd0,
0x49731d0,
0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)>
Result DAG:
SelectionDAG has 21 nodes:
  0x49606f0: ch = EntryToken [ORD=1] [ID=0]

  0x4972cd0: i8 = undef [ORD=1] [ID=2]

  0x49735d0: i8 = Constant<1> [ID=3]

    0x4977920: i8 = TargetGlobalAddress<i16* @b> 0 [ID=4]

  0x4972fd0: i8 = SPISD::GLOBAL_TRANSFER 0x4977920 [ID=6]

    0x49606f0: <multiple use>
    0x4972fd0: <multiple use>
    0x4972cd0: <multiple use>
  0x4976c20: i8,ch = load 0x49606f0, 0x4972fd0,
0x4972cd0<LD1[@b](align=2)>
[ID=8]

    0x49606f0: <multiple use>
      0x4972fd0: <multiple use>
      0x49735d0: <multiple use>
    0x4976d20: i8 = add 0x4972fd0, 0x49735d0 [ID=9]

    0x4972cd0: <multiple use>
  0x4976e20: i8,ch = load 0x49606f0, 0x4976d20, 0x4972cd0<LD1[@b+1]>
[ID=12]

    0x49606f0: <multiple use>
        0x4972ed0: i8 = TargetGlobalAddress<i16* @a> 0 [ID=5]

      0x4977020: i8 = SPISD::GLOBAL_TRANSFER 0x4972ed0 [ID=7]

      0x49735d0: <multiple use>
    0x49736d0: i8 = add 0x4977020, 0x49735d0 [ID=11]

    0x4972cd0: <multiple use>
  0x49737d0: i8,ch = load 0x49606f0, 0x49736d0, 0x4972cd0<LD1[@a+1]>
[ID=14]

    0x4972bd0: <multiple use>
    0x49731d0: i32 = TargetGlobalAddress<i16* @a> 0

    0x4976c20: <multiple use>
      0x49606f0: <multiple use>
      0x49737d0: <multiple use>
      0x4976c20: <multiple use>
      0x4976e20: <multiple use>
    0x49730d0: ch = TokenFactor 0x49606f0, 0x49737d0:1, 0x4976c20:1,
0x4976e20:1

  0x4977a20: ch,glue = addcmr 0x4972bd0, 0x49731d0, 0x4976c20,
0x49730d0<Mem:LD1[@a](align=2)>

  0x4972bd0: i8 = Register %noreg

  0x4976f20: i32 = TargetGlobalAddress<i16* @a> + 1

      0x4977a20: <multiple use>
        0x4972bd0: <multiple use>
        0x4976f20: <multiple use>
          0x49737d0: <multiple use>
          0x4976e20: <multiple use>
          0x4977a20: <multiple use>
        0x4977820: i8,glue = adde 0x49737d0, 0x4976e20, 0x4977a20:1 [ID=16]

        0x4972bd0: <multiple use>
        0x4976f20: <multiple use>
        0x4977a20: <multiple use>
      0x49738d0: ch = MOVmr 0x4972bd0, 0x4976f20, 0x4977820, 0x4972bd0,
0x4976f20, 0x4977a20

    0x4977c80: ch = TokenFactor 0x4977a20, 0x49738d0

  0x49733d0: ch = RET 0x4977c80

=====the  said TF Node was at 0x49730d0.
it was ADDC's last operand,input chain.

4)the DAG after ADDE was seleced:
Select node:
0x4977820: i8,ch,glue = <<Unknown Machine Node #65516>> 0x49737d0,
0x4972bd0, 0x4972dd0, 0x49606f0, 0x4977a20:1<Mem:LD1[@b+1]>
Result node:
0x4977820: i8,ch,glue = <<Unknown Machine Node #65516>> 0x49737d0,
0x4972bd0, 0x4972dd0, 0x49606f0, 0x4977a20:1<Mem:LD1[@b+1]>
Result DAG:
SelectionDAG has 20 nodes:
  0x49606f0: ch = EntryToken [ORD=1] [ID=0]

  0x4972cd0: i8 = undef [ORD=1] [ID=2]

    0x49606f0: <multiple use>
      0x4977920: i8 = TargetGlobalAddress<i16* @b> 0 [ID=4]

    0x4972fd0: i8 = SPISD::GLOBAL_TRANSFER 0x4977920 [ID=6]

    0x4972cd0: <multiple use>
  0x4976c20: i8,ch = load 0x49606f0, 0x4972fd0,
0x4972cd0<LD1[@b](align=2)>
[ID=8]

    0x49606f0: <multiple use>
        0x4972ed0: i8 = TargetGlobalAddress<i16* @a> 0 [ID=5]

      0x4977020: i8 = SPISD::GLOBAL_TRANSFER 0x4972ed0 [ID=7]

      0x49735d0: i8 = Constant<1> [ID=3]

    0x49736d0: i8 = add 0x4977020, 0x49735d0 [ID=11]

    0x4972cd0: <multiple use>
  0x49737d0: i8,ch = load 0x49606f0, 0x49736d0, 0x4972cd0<LD1[@a+1]>
[ID=14]

    0x49737d0: <multiple use>
    0x4972bd0: <multiple use>
    0x4972dd0: i32 = TargetGlobalAddress<i16* @b> + 1

    0x49606f0: <multiple use>
    0x4977a20: <multiple use>
  0x4977820: i8,ch,glue = ADDerm 0x49737d0, 0x4972bd0, 0x4972dd0,
0x49606f0, 0x4977a20:1<Mem:LD1[@b+1]>

    0x4972bd0: <multiple use>
    0x49731d0: i32 = TargetGlobalAddress<i16* @a> 0

    0x4976c20: <multiple use>
      0x49606f0: <multiple use>
      0x49737d0: <multiple use>
      0x4976c20: <multiple use>
      0x4977820: <multiple use>
    0x49730d0: ch = TokenFactor 0x49606f0, 0x49737d0:1, 0x4976c20:1,
0x4977820:1

  0x4977a20: ch,glue = addcmr 0x4972bd0, 0x49731d0, 0x4976c20,
0x49730d0<Mem:LD1[@a](align=2)>

  0x4972bd0: i8 = Register %noreg

  0x4976f20: i32 = TargetGlobalAddress<i16* @a> + 1

      0x4977a20: <multiple use>
        0x4972bd0: <multiple use>
        0x4976f20: <multiple use>
        0x4977820: <multiple use>
        0x4972bd0: <multiple use>
        0x4976f20: <multiple use>
        0x4977a20: <multiple use>
      0x49738d0: ch = MOVmr 0x4972bd0, 0x4976f20, 0x4977820, 0x4972bd0,
0x4976f20, 0x4977a20

    0x4977c80: ch = TokenFactor 0x4977a20, 0x49738d0

  0x49733d0: ch = RET 0x4977c80


5)the change happened to the said TF node
   from:  0x49730d0: ch = TokenFactor 0x49606f0, 0x49737d0:1, 0x4976c20:1,
0x4976e20:1
   to:     0x49730d0: ch = TokenFactor 0x49606f0, 0x49737d0:1, 0x4976c20:1,
0x4977820:1

6)ADDE node.

  0x4977820: i8,ch,glue = ADDerm 0x49737d0, 0x4972bd0, 0x4972dd0,
0x49606f0, 0x4977a20:1<Mem:LD1[@b+1]>

0x4977820 became  the last operand of the said TF Node after ADDE was
selected.
7) the loop

  0x4977a20: ch,glue = addcmr 0x4972bd0, 0x49731d0, 0x4976c20,
0x49730d0<Mem:LD1[@a](align=2)>
  0x49730d0: ch = TokenFactor 0x49606f0, 0x49737d0:1, 0x4976c20:1,
0x4977820:1
  0x4977820: i8,ch,glue = ADDerm 0x49737d0, 0x4972bd0, 0x4972dd0,
0x49606f0, 0x4977a20:1<Mem:LD1[@b+1]>



Cheers.

hilbert






On Sat, Apr 26, 2014 at 3:17 PM, Tim Northover <t.p.northover at
gmail.com>wrote:
> Hi Hilbert,
>
> > let Constraints="$dst=$op0",mayStore=1,
>
> Are you sure you mean "mayStore" here and not
"mayLoad"?
>
> > very bad, all uses of  input chain was replaced with ADDErm  Node.
>
> Since your ADDErm is also a load, it is going to need an input chain
> of some kind (and hence OPFL_Chain) so that's not surprising on its
> own.
>
> > so the created token factor node depends on the ADDErm node  after the
> > replacement.
>
> I don't suppose you could post the output of
"-view-isel-dags" &
> "-view-sched-dags"? I've got some ideas on how to reproduce
what
> you're seeing, but I need the exact DAGs to have much chance.
>
> It sounds like it *might* be a bug in HandleMergeInputChains, if it
> doesn't take glue into account somehow.
>
> Cheers.
>
> Tim.
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140428/74c9713c/attachment.html>

Reasonably Related Threads

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

llvm dev - Apr 2014 - [LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

[LLVMdev] How can I get rid of "OPFL_Chain" in myCPUGenInstrInfo.inc

Reasonably Related Threads