Boris Boesler
2014-Nov-03 21:56 UTC
[LLVMdev] Virtual register def doesn't dominate all uses
Hi Quentin,>> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. > > And what about view-sched-dags?The DAG looks like I described below (*)> This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection problem. > If that is the case, you can use -debug-only=isel to help you figuring out what is the problem.This is the add node (sum + v3) from the dot file (-view-isel-dags): Node0x7fef2a033610 [shape=record,shape=Mrecord,label="{{<s0>0|<s1>1}|add [ORD=21] [ID=29]|0x7fef2a033610|{<d0>i32}}"]; The debug output (-debug-only=isel) is: ISEL: Starting pattern match on root node: 0x7fef2a033610: i32 = add 0x7fef2a033410, 0x7fef2a032f10 [ORD=21] [ID=29] Skipped scope entry (due to false predicate) at index 3, continuing at 2566 Match failed at index 2575 Continuing at 2628 Match failed at index 2639 Continuing at 2659 Match failed at index 2663 Continuing at 2700 Continuing at 2701 Continuing at 2702 Match failed at index 2703 Continuing at 2817 Match failed at index 2818 Continuing at 2901 Match failed at index 2902 Continuing at 2985 Match failed at index 2986 Continuing at 3100 Match failed at index 3101 Continuing at 3215 Match failed at index 3216 Continuing at 3330 Match failed at index 3331 Continuing at 3445 Match failed at index 3447 Continuing at 3591 Match failed at index 3592 Continuing at 3706 Match failed at index 3707 Continuing at 3790 Match failed at index 3791 Continuing at 3874 Match failed at index 3875 Continuing at 3958 Match failed at index 3959 Continuing at 4046 Match failed at index 4047 Continuing at 4081 Match failed at index 4082 Continuing at 4116 Match failed at index 4117 Continuing at 4179 Match failed at index 4180 Continuing at 4209 Match failed at index 4210 Continuing at 4230 Match failed at index 4231 Continuing at 4261 Match failed at index 4262 Continuing at 4309 Match failed at index 4310 Continuing at 4322 Morphed node: 0x7fef2a033610: i32 = MVrr 0x7fef2a033610 [ORD=21] Does the add operation become a MOVE instruction, or is this a chain of rules? (*)>>>>>> But if I use the statement "int res = v1 + v2 + v3;" something strange happens: all arguments are stored in the stack-frame and the local variables are initialized. Now, the variables v1 and v2 are loaded, but they are not used (no ADD instructions) and a MOVE instruction register to register is generated that uses itself as an operand. This register should be stored and should be used as function result.Boris
Quentin Colombet
2014-Nov-03 22:30 UTC
[LLVMdev] Virtual register def doesn't dominate all uses
On Nov 3, 2014, at 1:56 PM, Boris Boesler <baembel at gmx.de> wrote:> Hi Quentin, > >>> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. >> >> And what about view-sched-dags? > > The DAG looks like I described below (*) > > >> This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection problem. >> If that is the case, you can use -debug-only=isel to help you figuring out what is the problem. > > This is the add node (sum + v3) from the dot file (-view-isel-dags): > > Node0x7fef2a033610 [shape=record,shape=Mrecord,label="{{<s0>0|<s1>1}|add [ORD=21] [ID=29]|0x7fef2a033610|{<d0>i32}}"]; > > The debug output (-debug-only=isel) is: > > ISEL: Starting pattern match on root node: 0x7fef2a033610: i32 = add 0x7fef2a033410, 0x7fef2a032f10 [ORD=21] [ID=29] > > Skipped scope entry (due to false predicate) at index 3, continuing at 2566 > Match failed at index 2575 > Continuing at 2628 > Match failed at index 2639 > Continuing at 2659 > Match failed at index 2663 > Continuing at 2700 > Continuing at 2701 > Continuing at 2702 > Match failed at index 2703 > Continuing at 2817 > Match failed at index 2818 > Continuing at 2901 > Match failed at index 2902 > Continuing at 2985 > Match failed at index 2986 > Continuing at 3100 > Match failed at index 3101 > Continuing at 3215 > Match failed at index 3216 > Continuing at 3330 > Match failed at index 3331 > Continuing at 3445 > Match failed at index 3447 > Continuing at 3591 > Match failed at index 3592 > Continuing at 3706 > Match failed at index 3707 > Continuing at 3790 > Match failed at index 3791 > Continuing at 3874 > Match failed at index 3875 > Continuing at 3958 > Match failed at index 3959 > Continuing at 4046 > Match failed at index 4047 > Continuing at 4081 > Match failed at index 4082 > Continuing at 4116 > Match failed at index 4117 > Continuing at 4179 > Match failed at index 4180 > Continuing at 4209 > Match failed at index 4210 > Continuing at 4230 > Match failed at index 4231 > Continuing at 4261 > Match failed at index 4262 > Continuing at 4309 > Match failed at index 4310 > Continuing at 4322 > Morphed node: 0x7fef2a033610: i32 = MVrr 0x7fef2a033610 [ORD=21] > > > Does the add operation become a MOVE instruction, or is this a chain of rules?Yes, your add becomes a MVrr instruction. This is likely the problem. Do you know how to debug this, or do you want me to give you basic directions? -Quentin> > (*) >>>>>>> But if I use the statement "int res = v1 + v2 + v3;" something strange happens: all arguments are stored in the stack-frame and the local variables are initialized. Now, the variables v1 and v2 are loaded, but they are not used (no ADD instructions) and a MOVE instruction register to register is generated that uses itself as an operand. This register should be stored and should be used as function result. > > Boris >
Boris Boesler
2014-Nov-05 14:47 UTC
[LLVMdev] Virtual register def doesn't dominate all uses
Hi Quentin, Am 03.11.2014 um 23:30 schrieb Quentin Colombet <qcolombet at apple.com>:>> Continuing at 4309 >> Match failed at index 4310 >> Continuing at 4322 >> Morphed node: 0x7fef2a033610: i32 = MVrr 0x7fef2a033610 [ORD=21] >> >> >> Does the add operation become a MOVE instruction, or is this a chain of rules? > > Yes, your add becomes a MVrr instruction. This is likely the problem. > Do you know how to debug this, or do you want me to give you basic directions?I had a look at the matcher table and it looks as follows: /*4309*/ /*Scope*/ 12, /*->4322*/ /*4310*/ OPC_CheckOpcode, TARGET_VAL(MBPISD::RET_FLAG), /*4313*/ OPC_RecordNode, // #0 = 'retflag' chained node /*4314*/ OPC_CaptureGlueInput, /*4315*/ OPC_EmitMergeInputChains1_0, /*4316*/ OPC_MorphNodeTo, TARGET_VAL(MyTarget::RETL), 0|OPFL_Chain|OPFL_GlueInput|OPFL_Variadic0, 0/*#VTs*/, 0/*#Ops*/, // Src: (retflag) - Complexity = 3 // Dst: (RETL) /*4322*/ /*Scope*/ 11, /*->4334*/ /*4323*/ OPC_RecordNode, // #0 = $a /*4324*/ OPC_CheckType, MVT::i32, /*4326*/ OPC_MorphNodeTo, TARGET_VAL(MyTarget::MVrr), 0, 1/*#VTs*/, MVT::i32, 1/*#Ops*/, 0, // Src: AllRegs:i32:$a - Complexity = 3 // Dst: (MVrr:i32 AllRegs:i32:$a) /*4334*/ /*Scope*/ 14, /*->4349*/ /*4335*/ OPC_CheckOpcode, TARGET_VAL(ISD::ADD), /*4338*/ OPC_RecordChild0, // #0 = $a /*4339*/ OPC_RecordChild1, // #1 = $b /*4340*/ OPC_MorphNodeTo, TARGET_VAL(MyTarget::ADDrrr), 0, Matching fails from the beginning because no pattern matches (that's correct) and it fails at index 4310 because ADD != MBPISD::RET_FLAG. Now, matching continues at index 4322 and the only check there is the typecheck MVT::i32 of the input. It doesn't check any opcodes! That means that if no pattern matches till this point any input becomes a MVrr, which is completely wrong. The pattern, that should match ADDrrr, is right at index 4334. Well, MV patterns (ala [(set AllRegs:$dst, AllRegs:$a)]) are the first ones in my .td files. I'm guessing they appear in the same order in the matcher table. Cross-check: Move the MV-patterns from the beginning to the end. Voila, it works. I assume this is a bug/imperfection in the table match generator. Knowing that, I can continue my work. Thanks, Boris