[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