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

[Krzysztof Parzyszek via llvm-dev]

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