llvm dev - Nov 2014 - [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

Hi Boris,

On 5 November 2014 06:47, Boris Boesler <baembel at gmx.de>
wrote:
>  Cross-check: Move the MV-patterns from the beginning to the end. Voila, it
works.
It would be better to delete those patterns entirely. They'll always
match (if asked) and never give a sane result.
>  I assume this is a bug/imperfection in the table match generator.
It possibly should be a compile-time error, if we can detect it
reliably (maybe look for at least one real node being consumed?). But
the kind of pattern it's trying to represent just shouldn't exist.

Cheers.

Tim.

Hi!

Am 05.11.2014 um 16:05 schrieb Tim Northover <t.p.northover at gmail.com>:
> Hi Boris,
> 
> On 5 November 2014 06:47, Boris Boesler <baembel at gmx.de> wrote:
>> Cross-check: Move the MV-patterns from the beginning to the end. Voila,
it works.
> 
> It would be better to delete those patterns entirely. They'll always
> match (if asked) and never give a sane result.
 Hm, these are no patterns like "def : Pat<..>;". These are
patterns inside instructions, and I do have to specify them to use them in
copyPhysReg(), don't I?

Boris