[LLVMdev] Virtual register def doesn't dominate all uses

[Boris Boesler]

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