[LLVMdev] Types inference in tblgen: Multiple exceptions

[Ivan Llopard]

On 10/12/2011 01:25, Jim Grosbach wrote:
> On Dec 9, 2011, at 4:12 PM, Ivan Llopard wrote:
>
>> 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.
> There are an unfortunately large number of places in tablegen where assert() has been used when a user level diagnostic was appropriate. We've been fixing them, but haven't gotten them all yet. Can you file a bugzilla? Obviously a small testcase would be great, but if it's indeed an assertion failure, even just the backtrace from that would be very helpful.
>
> Thanks!
>    Jim
Hello Jim,

I've submitted the bug, its ID is 11529.
>>>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev