[llvm-dev] BPF backend with vector operations - error "Could not infer all types in, pattern!"

Alex Susu via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 3 02:49:50 PDT 2016


   Hello.
     Note: I'm using TableGen from Nov 2015 - I can't use the one from May 2016 directly - 
new errors appear in my current TableGen files. But if you advise I can switch to newest 
version of TableGen.

     The error that I described in the previous email down here is weird: when imm is
explicitly i64 instead of being polymorphic (and TableGen unifies it with i64 or v8i64 
since now I have vector values and registers in my back end) the resulting GenDAGISel.inc 
has fundamental differences at MatcherTable.
     Is this a more hidden error of TableGen?

     More exactly, originally I had:
      def i64immSExt32 : PatLeaf<(imm),
          [{return isInt<32>(N->getSExtValue()); }]>;

     Since I get a few errors like:
       SLL_ri: (set GPR:i64:$dst, (shl:i64 GPR:i64:$src2, (imm:{i64:v8i64}):$imm))
       Included from Connex.td:26:
       Included from ConnexInstrInfo.td:22:
       ConnexInstrInfo_scalar.td:297:3: error: In SLL_ri: Could not infer all types in 
pattern!
       defm SLL : ALU<0x6, "sll", shl>;
       ^
       Included from Connex.td:26:
       Included from ConnexInstrInfo.td:22:
       ConnexInstrInfo_scalar.td:288:3: note: instantiated from multiclass
       def _ri : ALU_RI<Opc, OpcodeStr, OpNode>;
       ^

     I decided to use:
          def i64immSExt32 : PatLeaf<(i64 imm),
                   [{return isInt<32>(N->getSExtValue()); }]>;


    But:
     - My new GenDAGISel.inc has:
       /*928*/     /*SwitchOpcode*/ 30, TARGET_VAL(ISD::ADD),// ->961
       /*931*/       OPC_SwitchType /*2 cases */, 13, MVT::i64,// ->947
       /*934*/         OPC_RecordNode, // #0 = $addr
       /*935*/         OPC_CheckComplexPat, /*CP*/1, /*#*/0, // SelectFIAddr:$addr #1 #2
       /*938*/         OPC_MorphNodeTo, TARGET_VAL(Connex::FI_ri), 0,
                     1/*#VTs*/, MVT::i64, 2/*#Ops*/, 1, 2,.
                 // Src: FIri:i64:$addr - Complexity = 9
                 // Dst: (FI_ri:i64 FIri:i64:$addr)

       /*947*/       /*SwitchType*/ 11, MVT::v8i64,// ->960
       /*949*/         OPC_RecordChild0, // #0 = $ws
       /*950*/         OPC_RecordChild1, // #1 = $wt
       /*951*/         OPC_MorphNodeTo, TARGET_VAL(Connex::ADDV_D), 0,
                     1/*#VTs*/, MVT::v8i64, 2/*#Ops*/, 0, 1,.
                 // Src: (add:v8i64 MSA128DOpnd:v8i64:$ws, MSA128DOpnd:v8i64:$wt) - 
Complexity = 3
                 // Dst: (ADDV_D:v8i64 MSA128DOpnd:v8i64:$ws, MSA128DOpnd:v8i64:$wt)
       /*960*/       0, // EndSwitchType
       /*961*/     /*SwitchOpcode*/ 69, TARGET_VAL(ISD::OR),// ->1033



      - and the original BPFGenDAGISel.inc has:
       /*807*/     /*SwitchOpcode*/ 53, TARGET_VAL(ISD::ADD),// ->863
       /*810*/       OPC_Scope, 15, /*->827*/ // 2 children in Scope
       /*812*/         OPC_RecordNode, // #0 = $addr
       /*813*/         OPC_CheckType, MVT::i64,
       /*815*/         OPC_CheckComplexPat, /*CP*/1, /*#*/0, // SelectFIAddr:$addr #1 #2
       /*818*/         OPC_MorphNodeTo, TARGET_VAL(BPF::FI_ri), 0,
                     1/*#VTs*/, MVT::i64, 2/*#Ops*/, 1, 2,.
                 // Src: FIri:i64:$addr - Complexity = 9
                 // Dst: (FI_ri:i64 FIri:i64:$addr)

       /*827*/       /*Scope*/ 34, /*->862*/
       /*828*/         OPC_RecordChild0, // #0 = $src2
       /*829*/         OPC_RecordChild1, // #1 = $imm
       /*830*/         OPC_Scope, 19, /*->851*/ // 2 children in Scope
       /*832*/           OPC_MoveChild, 1,
       /*834*/           OPC_CheckOpcode, TARGET_VAL(ISD::Constant),
       /*837*/           OPC_CheckPredicate, 0, // Predicate_i64immSExt32

       /*839*/           OPC_MoveParent,
       /*840*/           OPC_EmitConvertToTarget, 1,
       /*842*/           OPC_MorphNodeTo, TARGET_VAL(BPF::ADD_ri), 0,
                       1/*#VTs*/, MVT::i64, 2/*#Ops*/, 0, 2,.
                   // Src: (add:i64 GPR:i64:$src2, 
(imm:i64)<<P:Predicate_i64immSExt32>>:$imm) - Complexity = 7
                   // Dst: (ADD_ri:i64 GPR:i64:$src2, (imm:i64):$imm)
       /*851*/         /*Scope*/ 9, /*->861*/
       /*852*/           OPC_MorphNodeTo, TARGET_VAL(BPF::ADD_rr), 0,
                       1/*#VTs*/, MVT::i64, 2/*#Ops*/, 0, 1,.
                   // Src: (add:i64 i64:i64:$src2, i64:i64:$src) - Complexity = 3
                   // Dst: (ADD_rr:i64 i64:i64:$src2, i64:i64:$src)
       /*861*/         0, /*End of Scope*/
       /*862*/       0, /*End of Scope*/
       /*863*/     /*SwitchOpcode*/ 53, TARGET_VAL(ISD::OR),// ->919


   Best regards,
     Alex


On 6/2/2016 10:31 PM, Alex Susu wrote:
>    Hello.
>      I come back to this older thread.
>      Again, because of i64immSExt32 I receive TableGen error "Could not infer all types
> in, pattern!" (exact details written below). So far I'm not able to generate selection
> code with TableGen for the ADD_r* instructions, etc:
>             def i64immSExt32 : PatLeaf<(imm),
>                  [{return isInt<32>(N->getSExtValue()); }]>;
>
>      As in the case of https://groups.google.com/forum/#!topic/llvm-dev/LfltBGG9ru0 : "It
> seems that defining a new register class changes how the tblgen infers the types in the
> DAG patterns. So what is the right way to add a register class for a different type?"
>
>      Please help.
>
>    Thank you,
>      Alex
>
> On 1/9/2016 9:29 PM, RCU wrote:
>>    Hello.
>>      (WRONG: I solved this issue (from the previous email).)
>>
>>      Got inspired from http://comments.gmane.org/gmane.comp.compilers.llvm.devel/73619,
>> (also https://groups.google.com/forum/#!topic/llvm-dev/LfltBGG9ru0),
>> http://lists.llvm.org/pipermail/llvm-dev/2007-April/008843.html
>>
>>      What I did was to edit ConnexInstrInfo.td and replaced all occurrences:
>>          PatLeaf<(imm)
>>         %(which were ambiguous since the variable name ("in dag operator") does not have a
>> type and this poses issues to the Type inference algorithm, since I added in
>> ConnexRegisterInfo.td a second RegisterClass with type v2i64)
>>      with
>>          PatLeaf<(i64 imm)
>>      namely:
>>         - def i64immSExt32 : PatLeaf<(i64 imm),
>>                  [{return isInt<32>(N->getSExtValue()); }]>;
>>
>>    Best regards,
>>      Alex
>>
>> On 1/8/2016 1:31 AM, RCU wrote:
>>>    Hello.
>>>      I've tried to add some simple arithmetic vector operations to the BPF backend
>>> available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass
>>> (taken from the Mips backend):
>>>    def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128,
>>>                             (sequence "W%u", 0, 31)>;
>>> in order to support vector for example, ADD operations, I get the following error when
>>> building llc:
>>>    JEQ_ri:         (BPFbrcc i64:i64:$dst, (imm:i64)<<P:Predicate_i64immSExt32>>:$imm,
>>> (imm:{i64:v4i32})<<P:Predicate_BPF_CC_EQ>>, (bb:Other):$BrDst)
>>> Included from ~/LLVM/llvm38Nov2016/llvm/lib/Target/BPF/BPF.td:14:
>>> ~/LLVM/llvm38Nov2016/llvm/lib/Target/BPF/BPFInstrInfo.td:131:1: error: In JEQ_ri: Could
>>> not infer all types in pattern!
>>>    defm JEQ  : J<0x1, "jeq",  BPF_CC_EQ>;
>>>
>>>
>>>    The error is a bit cryptic - basically it seems that we can have 2 different value
>>> types (i64 and v4i32) for immediate operand imm. I guess this is because in
>>> BPFRegisterInfo.td I define also another RegisterClass:
>>>    def GPR : RegisterClass<"Connex", [i64], 64, (add (sequence "R%u", 0, 31))>;
>>>
>>>
>>>    Can somebody tell me how can I get rid of this <<Could not infer all types in
>>> pattern!>> error message? (I can provide more info, if required.)
>>>
>>>    Thank you,
>>>      Alex


More information about the llvm-dev mailing list