[llvm-dev] Are there some strong naming conventions in TableGen?

[Anton Korobeynikov via llvm-dev]

Krzysztof is correct - there is no particular naming scheme involved
besides some reserved stuff. Basically here tablgen is complaining
that the node type "IMM16Operand" is unknown - you'd need to define
it.

On Thu, Jul 27, 2017 at 5:07 PM, Krzysztof Parzyszek via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> There are some names that TableGen has some internal knowledge of, and "imm"
> is one of them.  At the same time there are no conventions regarding other,
> non-reserved names.  Whether you call something IMM1 or imm1 makes no
> difference as long as you don't use the exact reserved name.
>
> -Krzysztof
>
>
> On 7/27/2017 7:22 AM, Dominique Torette via llvm-dev wrote:
>>
>> Hi,
>>
>> For the development of a new micro-controller backend, I try to lowering
>> the following store SDNode:   t5: ch = store<ST2[%ptr2](align=4)> t0,
>> Constant:i16<3>, FrameIndex:i16<1>, undef:i16
>>
>> I have defined the following instruction and associated DAG pattern.
>>
>>              def MOVSUTO_A_i32o : CLPFPU_A_i32o_Inst<0b1000001101,
>>
>>                                                  (ins
>> IMM16Operand:$ImmA,FPUaOffsetOperand:$OffsetB),
>>
>>                                                  (outs ),
>>
>>                                                  [],
>>
>>
>> "movsuto_a\t$ImmA,$OffsetB","I32O",
>>
>>                                                  [(store (i16
>> IMM16Operand:$ImmA), FPUaOffsetOperand:$OffsetB)],NoItinerary>;
>>
>> While building CLPGenDAGISel.inc, I got the following error:
>>
>>
>> -------------------------------------------------------------------------------------------------
>>
>> Unknown leaf kind: IMM16Operand:i16:$ImmA
>>
>> …
>>
>> #7 0x00000000005210a1 (anonymous
>> namespace)::MatcherGen::EmitLeafMatchCode(llvm::TreePatternNode const*)
>> /home/dte/Projects/CLP/clp-llvm/trunk/llvm-project/llvm/utils/TableGen/DAGISelMatcherGen.cpp:286:0
>>
>>
>> -------------------------------------------------------------------------------------------------
>>
>> While looking the DAGISelMatcherGen.cpp around line 286 (version 3.8.0),
>> I’ve found such a kind of code
>>
>>
>> -------------------------------------------------------------------------------------------------
>>
>> // Direct match against an integer constant.
>>
>> *if*(IntInit*II = dyn_cast<IntInit>(N->getLeafValue())) {
>>
>> // If this is the root of the _dag_ we're matching, we emit a redundant
>> opcode
>>
>> // check to ensure that this gets folded into the normal top-level
>>
>> // OpcodeSwitch.
>>
>> *if*(N == Pattern.getSrcPattern()) {
>>
>> *const*SDNodeInfo&NI = CGP._getSDNodeInfo_(CGP._getSDNodeNamed_("_imm_"));
>>
>>        AddMatcher(*new*CheckOpcodeMatcher(NI));
>>
>>      }
>>
>> *return*AddMatcher(*new*CheckIntegerMatcher(II->getValue()));
>>
>>    }
>>
>>
>> -------------------------------------------------------------------------------------------------
>>
>> This code seems to retrieve some Node definition based on a naming
>> convention related to the “imm” string.
>>
>> Are such naming conventions quite common for TableGen target descition
>> input file?
>>
>> Do I have to rename IMM16Operand into something like imm16Operand?
>>
>> Thanks in advance.        Dominique Torette.
>>
>>
>>
>>
>>
>> http://www.spacebel.be/wp-content/uploads/2011/06/image-sign-sbp.jpg
>>
>> *Dominique Torette*
>> System Architect
>> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur
>> Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20
>> www.spacebel.be <http://www.spacebel.be/>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> E-MAIL DISCLAIMER
>>
>> The present message may contain confidential and/or legally privileged
>> information. If you are not the intended addressee and in case of a
>> transmission error, please notify the sender immediately and destroy this
>> E-mail. Disclosure, reproduction or distribution of this document and its
>> possible attachments is strictly forbidden.
>>
>> SPACEBEL denies all liability for incomplete, improper, inaccurate,
>> intercepted, (partly) destroyed, lost and/or belated transmission of the
>> current information given that unencrypted electronic transmission cannot
>> currently be guaranteed to be secure or error free.
>> Upon request or in conformity with formal, contractual agreements, an
>> originally signed hard copy will be sent to you to confirm the information
>> contained in this E-mail.
>>
>> SPACEBEL denies all liability where E-mail is used for private use.
>>
>> SPACEBEL cannot be held responsible for possible viruses that might
>> corrupt this message and/or your computer system.
>>
>> -------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
> The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University