Path: blob/main/contrib/llvm-project/llvm/utils/TableGen/TableGenBackends.h
35258 views
//===- TableGenBackends.h - Declarations for LLVM TableGen Backends -------===//1//2// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.3// See https://llvm.org/LICENSE.txt for license information.4// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception5//6//===----------------------------------------------------------------------===//7//8// This file contains the declarations for all of the LLVM TableGen9// backends. A "TableGen backend" is just a function. See below for a10// precise description.11//12//===----------------------------------------------------------------------===//1314#ifndef LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H15#define LLVM_UTILS_TABLEGEN_TABLEGENBACKENDS_H1617#include <string>1819// A TableGen backend is a function that looks like20//21// EmitFoo(RecordKeeper &RK, raw_ostream &OS /*, anything else you need */ )22//23// What you do inside of that function is up to you, but it will usually24// involve generating C++ code to the provided raw_ostream.25//26// The RecordKeeper is just a top-level container for an in-memory27// representation of the data encoded in the TableGen file. What a TableGen28// backend does is walk around that in-memory representation and generate29// stuff based on the information it contains.30//31// The in-memory representation is a node-graph (think of it like JSON but32// with a richer ontology of types), where the nodes are subclasses of33// Record. The methods `getClass`, `getDef` are the basic interface to34// access the node-graph. RecordKeeper also provides a handy method35// `getAllDerivedDefinitions`. Consult "include/llvm/TableGen/Record.h" for36// the exact interfaces provided by Record's and RecordKeeper.37//38// A common pattern for TableGen backends is for the EmitFoo function to39// instantiate a class which holds some context for the generation process,40// and then have most of the work happen in that class's methods. This41// pattern partly has historical roots in the previous TableGen backend API42// that involved a class and an invocation like `FooEmitter(RK).run(OS)`.43//44// Remember to wrap private things in an anonymous namespace. For most45// backends, this means that the EmitFoo function is the only thing not in46// the anonymous namespace.4748// FIXME: Reorganize TableGen so that build dependencies can be more49// accurately expressed. Currently, touching any of the emitters (or50// anything that they transitively depend on) causes everything dependent51// on TableGen to be rebuilt (this includes all the targets!). Perhaps have52// a standalone TableGen binary and have the backends be loadable modules53// of some sort; then the dependency could be expressed as being on the54// module, and all the modules would have a common dependency on the55// TableGen binary with as few dependencies as possible on the rest of56// LLVM.5758namespace llvm {5960class raw_ostream;61class RecordKeeper;6263void EmitMapTable(RecordKeeper &RK, raw_ostream &OS);6465// Defined in DecoderEmitter.cpp66void EmitDecoder(RecordKeeper &RK, raw_ostream &OS,67const std::string &PredicateNamespace);6869} // namespace llvm7071#endif727374