thr3ads.net - llvm dev - [LLVMdev] Types inference in tblgen: Multiple exceptions [Dec 2011]

If this information is useful, please help other people find it:
Share via:

Llopard Ivan

2011-Dec-09 12:46 UTC

[LLVMdev] Types inference in tblgen: Multiple exceptions

Hi all,

I am writing a back-end for a processor that has complex type registers. 
It has two functional units to perform complex multiplications.
 From clang, I emulate a complex multiplication using vectors and, at 
the IR, I got this tblgen-friendly pattern (real component) :

(set RARegs:$dst, (insertelt RARegs:$src,
           (i16 (trunc (add
            (ncmul
             (sext (i16 (extractelt RARegs:$a, imm))),
             (sext (i16 (extractelt RARegs:$b, imm)))
             ),
            (ncmul
             (sext (i16 (extractelt RARegs:$a, imm))),
             (sext (i16 (extractelt RARegs:$b, imm)))
            )
            ))),
           imm) )

where RARegs is a register class of type [i32, v2i16]. I want to match 
that pattern in order to have one instruction which takes 2 vectors 
(complex numbers) and gives me another vector. Unfortunately, I am 
running into multiple tblgen type inference exceptions. I am new to llvm 
codegen.

First of all, I realized that I need to explicitly cast intermediate i16 
type results because they are not supported by the architecture, is it 
right?
For example, if I do not cast extractelt's node type I get the following 
error when I run tblgen with -gen-instr-info:

llvm[3]: Building Meph.td instruction information with tblgen
llvm-tblgen: llvm/include/llvm/ADT/SmallVector.h:150: T& 
llvm::SmallVectorTemplateCommon<T>::operator[](unsigned int) [with T = 
llvm::MVT::SimpleValueType]: Assertion `begin() + idx < end()' failed.

which comes from utils/TableGen/CodeGenDAGPatterns.cpp:450:

   for (unsigned i = 1, e = Other.TypeVec.size(); i != e; ++i)
     if (isInteger(Other.TypeVec[i]) && Other.TypeVec[i] >
LargestInt)
       LargestInt = Other.TypeVec[i];

but Other.TypeVec is empty throwing an exception when accessing 
Other.TypeVec[1].

As far as I know, tblgen analyzes sext node and tries to infer operand 
types by applying the specified type constraints of the node. The 2nd 
type constraint of sext enforces extractelt to be scalar and extractelt 
gets i32:v2i16 types (legal types or RARegs types). After that, it tries 
to apply the 3rd type constraint (SDTCisOpSmallerThanOp) and it reaches 
the abnormal condition I shown.

I presume this is a bug in tblgen, should not it verify that TypeVec is 
empty before entering the loop ?

Casting intermediate i16 type results, I manage to generate instruction 
information but it throws another exception when generating the 
instruction selector :-(.

vtInt:     (vt:Other)<<P:Predicate_vtInt>>
Type constraint application shouldn't fail!

Looking again into the code, tblgen does not take into account the 
explicit casts when generating the instruction selector (RemoveAllTypes 
-> InferPossibleTypes) so it gets stuck earlier into the pattern 
(insertelt-trunc). insertelt enforces trunc to be scalar and I have the 
same situation as before. Do you know how can I solve this problem ?
If it is either not possible or too hard, how should I proceed to detect 
the pattern ?


Ivan

Eli Friedman

2011-Dec-09 23:28 UTC

head link

[LLVMdev] Types inference in tblgen: Multiple exceptions

On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan <ivanllopard at gmail.com>
wrote:> Hi all,
>
> I am writing a back-end for a processor that has complex type registers.
> It has two functional units to perform complex multiplications.
>  From clang, I emulate a complex multiplication using vectors and, at
> the IR, I got this tblgen-friendly pattern (real component) :
>
> (set RARegs:$dst, (insertelt RARegs:$src,
>           (i16 (trunc (add
>            (ncmul
>             (sext (i16 (extractelt RARegs:$a, imm))),
>             (sext (i16 (extractelt RARegs:$b, imm)))
>             ),
>            (ncmul
>             (sext (i16 (extractelt RARegs:$a, imm))),
>             (sext (i16 (extractelt RARegs:$b, imm)))
>            )
>            ))),
>           imm) )
>
> where RARegs is a register class of type [i32, v2i16]. I want to match
> that pattern in order to have one instruction which takes 2 vectors
> (complex numbers) and gives me another vector. Unfortunately, I am
> running into multiple tblgen type inference exceptions. I am new to llvm
> codegen.
>
> First of all, I realized that I need to explicitly cast intermediate i16
> type results because they are not supported by the architecture, is it
> right?
> For example, if I do not cast extractelt's node type I get the
following
> error when I run tblgen with -gen-instr-info:
>
> llvm[3]: Building Meph.td instruction information with tblgen
> llvm-tblgen: llvm/include/llvm/ADT/SmallVector.h:150: T&
> llvm::SmallVectorTemplateCommon<T>::operator[](unsigned int) [with T
> llvm::MVT::SimpleValueType]: Assertion `begin() + idx < end()'
failed.
>
> which comes from utils/TableGen/CodeGenDAGPatterns.cpp:450:
>
>   for (unsigned i = 1, e = Other.TypeVec.size(); i != e; ++i)
>     if (isInteger(Other.TypeVec[i]) && Other.TypeVec[i] >
LargestInt)
>       LargestInt = Other.TypeVec[i];
>
> but Other.TypeVec is empty throwing an exception when accessing
> Other.TypeVec[1].
>
> As far as I know, tblgen analyzes sext node and tries to infer operand
> types by applying the specified type constraints of the node. The 2nd
> type constraint of sext enforces extractelt to be scalar and extractelt
> gets i32:v2i16 types (legal types or RARegs types). After that, it tries
> to apply the 3rd type constraint (SDTCisOpSmallerThanOp) and it reaches
> the abnormal condition I shown.
>
> I presume this is a bug in tblgen, should not it verify that TypeVec is
> empty before entering the loop ?
If TableGen crashes, it's a bug.
> Casting intermediate i16 type results, I manage to generate instruction
> information but it throws another exception when generating the
> instruction selector :-(.
>
> vtInt:     (vt:Other)<<P:Predicate_vtInt>>
> Type constraint application shouldn't fail!
>
> Looking again into the code, tblgen does not take into account the
> explicit casts when generating the instruction selector (RemoveAllTypes
> -> InferPossibleTypes) so it gets stuck earlier into the pattern
> (insertelt-trunc). insertelt enforces trunc to be scalar and I have the
> same situation as before. Do you know how can I solve this problem ?
> If it is either not possible or too hard, how should I proceed to detect
> the pattern ?
Your email doesn't really make one thing clear: does your architecture
have i16 registers?

-Eli

Ivan Llopard

2011-Dec-10 00:12 UTC

head link

[LLVMdev] Types inference in tblgen: Multiple exceptions

Hi Eli,
Thanks for your response. Please see my responses below.

On 10/12/2011 00:28, Eli Friedman wrote:> On Fri, Dec 9, 2011 at 4:46 AM, Llopard Ivan<ivanllopard at
gmail.com>  wrote:
>> Hi all,
>>
>> I am writing a back-end for a processor that has complex type
registers.
>> It has two functional units to perform complex multiplications.
>>   From clang, I emulate a complex multiplication using vectors and, at
>> the IR, I got this tblgen-friendly pattern (real component) :
>>
>> (set RARegs:$dst, (insertelt RARegs:$src,
>>            (i16 (trunc (add
>>             (ncmul
>>              (sext (i16 (extractelt RARegs:$a, imm))),
>>              (sext (i16 (extractelt RARegs:$b, imm)))
>>              ),
>>             (ncmul
>>              (sext (i16 (extractelt RARegs:$a, imm))),
>>              (sext (i16 (extractelt RARegs:$b, imm)))
>>             )
>>             ))),
>>            imm) )
>>
>> where RARegs is a register class of type [i32, v2i16]. I want to match
>> that pattern in order to have one instruction which takes 2 vectors
>> (complex numbers) and gives me another vector. Unfortunately, I am
>> running into multiple tblgen type inference exceptions. I am new to
llvm
>> codegen.
>>
>> First of all, I realized that I need to explicitly cast intermediate
i16
>> type results because they are not supported by the architecture, is it
>> right?
>> For example, if I do not cast extractelt's node type I get the
following
>> error when I run tblgen with -gen-instr-info:
>>
>> llvm[3]: Building Meph.td instruction information with tblgen
>> llvm-tblgen: llvm/include/llvm/ADT/SmallVector.h:150: T&
>> llvm::SmallVectorTemplateCommon<T>::operator[](unsigned int)
[with T >> llvm::MVT::SimpleValueType]: Assertion `begin() + idx< 
end()' failed.
>>
>> which comes from utils/TableGen/CodeGenDAGPatterns.cpp:450:
>>
>>    for (unsigned i = 1, e = Other.TypeVec.size(); i != e; ++i)
>>      if (isInteger(Other.TypeVec[i])&&  Other.TypeVec[i]> 
LargestInt)
>>        LargestInt = Other.TypeVec[i];
>>
>> but Other.TypeVec is empty throwing an exception when accessing
>> Other.TypeVec[1].
>>
>> As far as I know, tblgen analyzes sext node and tries to infer operand
>> types by applying the specified type constraints of the node. The 2nd
>> type constraint of sext enforces extractelt to be scalar and extractelt
>> gets i32:v2i16 types (legal types or RARegs types). After that, it
tries
>> to apply the 3rd type constraint (SDTCisOpSmallerThanOp) and it reaches
>> the abnormal condition I shown.
>>
>> I presume this is a bug in tblgen, should not it verify that TypeVec is
>> empty before entering the loop ?
> If TableGen crashes, it's a bug.
Yes, it crashes.>> Casting intermediate i16 type results, I manage to generate instruction
>> information but it throws another exception when generating the
>> instruction selector :-(.
>>
>> vtInt:     (vt:Other)<<P:Predicate_vtInt>>
>> Type constraint application shouldn't fail!
>>
>> Looking again into the code, tblgen does not take into account the
>> explicit casts when generating the instruction selector (RemoveAllTypes
>> ->  InferPossibleTypes) so it gets stuck earlier into the pattern
>> (insertelt-trunc). insertelt enforces trunc to be scalar and I have the
>> same situation as before. Do you know how can I solve this problem ?
>> If it is either not possible or too hard, how should I proceed to
detect
>> the pattern ?
> Your email doesn't really make one thing clear: does your architecture
> have i16 registers?
No, my architecture does not support i16 type.> -Eli

Possibly Parallel Threads

Search for more maybe matching threads

llvm dev - Dec 2011 - [LLVMdev] Types inference in tblgen: Multiple exceptions

[LLVMdev] Types inference in tblgen: Multiple exceptions

[LLVMdev] Types inference in tblgen: Multiple exceptions

[LLVMdev] Types inference in tblgen: Multiple exceptions

Possibly Parallel Threads