llvm/utils/TableGen/TableGenBackends.h

   1 //===- TableGenBackends.h - Declarations for LLVM TableGen Backends -------===//
   2 //
   3 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
   4 // See https://llvm.org/LICENSE.txt for license information.
   5 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
   6 //
   7 //===----------------------------------------------------------------------===//
   8 //
   9 // This file contains the declarations for all of the LLVM TableGen
  10 // backends. A "TableGen backend" is just a function. See below for a
  11 // precise description.
  12 //
  13 //===----------------------------------------------------------------------===//
  14
  15 #ifndef LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H
  16 #define LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H
  17
  18 #include <string>
  19
  20 // A TableGen backend is a function that looks like
  21 //
  22 //    EmitFoo(RecordKeeper &RK, raw_ostream &OS /*, anything else you need */ )
  23 //
  24 // What you do inside of that function is up to you, but it will usually
  25 // involve generating C++ code to the provided raw_ostream.
  26 //
  27 // The RecordKeeper is just a top-level container for an in-memory
  28 // representation of the data encoded in the TableGen file. What a TableGen
  29 // backend does is walk around that in-memory representation and generate
  30 // stuff based on the information it contains.
  31 //
  32 // The in-memory representation is a node-graph (think of it like JSON but
  33 // with a richer ontology of types), where the nodes are subclasses of
  34 // Record. The methods `getClass`, `getDef` are the basic interface to
  35 // access the node-graph.  RecordKeeper also provides a handy method
  36 // `getAllDerivedDefinitions`. Consult "include/llvm/TableGen/Record.h" for
  37 // the exact interfaces provided by Record's and RecordKeeper.
  38 //
  39 // A common pattern for TableGen backends is for the EmitFoo function to
  40 // instantiate a class which holds some context for the generation process,
  41 // and then have most of the work happen in that class's methods. This
  42 // pattern partly has historical roots in the previous TableGen backend API
  43 // that involved a class and an invocation like `FooEmitter(RK).run(OS)`.
  44 //
  45 // Remember to wrap private things in an anonymous namespace. For most
  46 // backends, this means that the EmitFoo function is the only thing not in
  47 // the anonymous namespace.
  48
  49 // FIXME: Reorganize TableGen so that build dependencies can be more
  50 // accurately expressed. Currently, touching any of the emitters (or
  51 // anything that they transitively depend on) causes everything dependent
  52 // on TableGen to be rebuilt (this includes all the targets!). Perhaps have
  53 // a standalone TableGen binary and have the backends be loadable modules
  54 // of some sort; then the dependency could be expressed as being on the
  55 // module, and all the modules would have a common dependency on the
  56 // TableGen binary with as few dependencies as possible on the rest of
  57 // LLVM.
  58
  59 namespace llvm {
  60
  61 class raw_ostream;
  62 class RecordKeeper;
  63
  64 void EmitMapTable(const RecordKeeper &RK, raw_ostream &OS);
  65
  66 // Defined in DecoderEmitter.cpp
  67 void EmitDecoder(const RecordKeeper &RK, raw_ostream &OS,
  68                  StringRef PredicateNamespace);
  69
  70 } // namespace llvm
  71
  72 #endif