Book a Demo!
CoCalc Logo Icon
StoreFeaturesDocsShareSupportNewsAboutPoliciesSign UpSign In
freebsd
GitHub Repository: freebsd/freebsd-src
Path: blob/main/contrib/llvm-project/llvm/utils/TableGen/TableGenBackends.h
35258 views
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(RecordKeeper &RK, raw_ostream &OS);
65
66
// Defined in DecoderEmitter.cpp
67
void EmitDecoder(RecordKeeper &RK, raw_ostream &OS,
68
const std::string &PredicateNamespace);
69
70
} // namespace llvm
71
72
#endif
73
74