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

Dominique Torette via llvm-dev llvm-dev at lists.llvm.org
Thu Jul 27 05:22:57 PDT 2017


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.
 -------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170727/2aecb181/attachment-0001.html>


More information about the llvm-dev mailing list