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

hilbert Wang huaibo.wang at gmail.com
Sun Apr 27 20:58:47 PDT 2014


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>


More information about the llvm-dev mailing list