brintos

brintos / llvm-project-archived public Read only

0
0
Text · 3.0 KiB · 261e171 Raw
70 lines · c
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-exception6//7//===----------------------------------------------------------------------===//8//9// This file contains the declarations for all of the LLVM TableGen10// backends. A "TableGen backend" is just a function. See below for a11// precise description.12//13//===----------------------------------------------------------------------===//14 15#ifndef LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H16#define LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H17 18// A TableGen backend is a function that looks like19//20//    EmitFoo(RecordKeeper &RK, raw_ostream &OS /*, anything else you need */ )21//22// What you do inside of that function is up to you, but it will usually23// involve generating C++ code to the provided raw_ostream.24//25// The RecordKeeper is just a top-level container for an in-memory26// representation of the data encoded in the TableGen file. What a TableGen27// backend does is walk around that in-memory representation and generate28// stuff based on the information it contains.29//30// The in-memory representation is a node-graph (think of it like JSON but31// with a richer ontology of types), where the nodes are subclasses of32// Record. The methods `getClass`, `getDef` are the basic interface to33// access the node-graph.  RecordKeeper also provides a handy method34// `getAllDerivedDefinitions`. Consult "include/llvm/TableGen/Record.h" for35// the exact interfaces provided by Record's and RecordKeeper.36//37// A common pattern for TableGen backends is for the EmitFoo function to38// instantiate a class which holds some context for the generation process,39// and then have most of the work happen in that class's methods. This40// pattern partly has historical roots in the previous TableGen backend API41// that involved a class and an invocation like `FooEmitter(RK).run(OS)`.42//43// Remember to wrap private things in an anonymous namespace. For most44// backends, this means that the EmitFoo function is the only thing not in45// the anonymous namespace.46 47// FIXME: Reorganize TableGen so that build dependencies can be more48// accurately expressed. Currently, touching any of the emitters (or49// anything that they transitively depend on) causes everything dependent50// on TableGen to be rebuilt (this includes all the targets!). Perhaps have51// a standalone TableGen binary and have the backends be loadable modules52// of some sort; then the dependency could be expressed as being on the53// module, and all the modules would have a common dependency on the54// TableGen binary with as few dependencies as possible on the rest of55// LLVM.56 57namespace llvm {58 59class raw_ostream;60class RecordKeeper;61 62void EmitMapTable(const RecordKeeper &RK, raw_ostream &OS);63 64// Defined in DecoderEmitter.cpp65void EmitDecoder(const RecordKeeper &RK, raw_ostream &OS);66 67} // namespace llvm68 69#endif70