[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
//===- JSONBackend.cpp - Generate a JSON dump of all records. -*- C++ -*-=====//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This TableGen back end generates a machine-readable representation
|
|
|
|
// of all the classes and records defined by the input, in JSON format.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/ADT/BitVector.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/TableGen/Error.h"
|
|
|
|
#include "llvm/TableGen/Record.h"
|
|
|
|
#include "llvm/TableGen/TableGenBackend.h"
|
|
|
|
#include "llvm/Support/JSON.h"
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "json-emitter"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
class JSONEmitter {
|
|
|
|
private:
|
|
|
|
RecordKeeper &Records;
|
|
|
|
|
|
|
|
json::Value translateInit(const Init &I);
|
|
|
|
json::Array listSuperclasses(const Record &R);
|
|
|
|
|
|
|
|
public:
|
|
|
|
JSONEmitter(RecordKeeper &R);
|
|
|
|
|
|
|
|
void run(raw_ostream &OS);
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace
|
|
|
|
|
|
|
|
JSONEmitter::JSONEmitter(RecordKeeper &R) : Records(R) {}
|
|
|
|
|
|
|
|
json::Value JSONEmitter::translateInit(const Init &I) {
|
|
|
|
|
|
|
|
// Init subclasses that we return as JSON primitive values of one
|
|
|
|
// kind or another.
|
|
|
|
|
|
|
|
if (isa<UnsetInit>(&I)) {
|
|
|
|
return nullptr;
|
|
|
|
} else if (auto *Bit = dyn_cast<BitInit>(&I)) {
|
|
|
|
return Bit->getValue() ? 1 : 0;
|
|
|
|
} else if (auto *Bits = dyn_cast<BitsInit>(&I)) {
|
|
|
|
json::Array array;
|
|
|
|
for (unsigned i = 0, limit = Bits->getNumBits(); i < limit; i++)
|
|
|
|
array.push_back(translateInit(*Bits->getBit(i)));
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(array);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
} else if (auto *Int = dyn_cast<IntInit>(&I)) {
|
|
|
|
return Int->getValue();
|
|
|
|
} else if (auto *Str = dyn_cast<StringInit>(&I)) {
|
|
|
|
return Str->getValue();
|
|
|
|
} else if (auto *Code = dyn_cast<CodeInit>(&I)) {
|
|
|
|
return Code->getValue();
|
|
|
|
} else if (auto *List = dyn_cast<ListInit>(&I)) {
|
|
|
|
json::Array array;
|
|
|
|
for (auto val : *List)
|
|
|
|
array.push_back(translateInit(*val));
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(array);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Init subclasses that we return as JSON objects containing a
|
|
|
|
// 'kind' discriminator. For these, we also provide the same
|
|
|
|
// translation back into TableGen input syntax that -print-records
|
|
|
|
// would give.
|
|
|
|
|
|
|
|
json::Object obj;
|
|
|
|
obj["printable"] = I.getAsString();
|
|
|
|
|
|
|
|
if (auto *Def = dyn_cast<DefInit>(&I)) {
|
|
|
|
obj["kind"] = "def";
|
|
|
|
obj["def"] = Def->getDef()->getName();
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(obj);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
} else if (auto *Var = dyn_cast<VarInit>(&I)) {
|
|
|
|
obj["kind"] = "var";
|
|
|
|
obj["var"] = Var->getName();
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(obj);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
} else if (auto *VarBit = dyn_cast<VarBitInit>(&I)) {
|
|
|
|
if (auto *Var = dyn_cast<VarInit>(VarBit->getBitVar())) {
|
|
|
|
obj["kind"] = "varbit";
|
|
|
|
obj["var"] = Var->getName();
|
|
|
|
obj["index"] = VarBit->getBitNum();
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(obj);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
}
|
|
|
|
} else if (auto *Dag = dyn_cast<DagInit>(&I)) {
|
|
|
|
obj["kind"] = "dag";
|
|
|
|
obj["operator"] = translateInit(*Dag->getOperator());
|
|
|
|
if (auto name = Dag->getName())
|
|
|
|
obj["name"] = name->getAsUnquotedString();
|
|
|
|
json::Array args;
|
|
|
|
for (unsigned i = 0, limit = Dag->getNumArgs(); i < limit; ++i) {
|
|
|
|
json::Array arg;
|
|
|
|
arg.push_back(translateInit(*Dag->getArg(i)));
|
|
|
|
if (auto argname = Dag->getArgName(i))
|
|
|
|
arg.push_back(argname->getAsUnquotedString());
|
|
|
|
else
|
|
|
|
arg.push_back(nullptr);
|
|
|
|
args.push_back(std::move(arg));
|
|
|
|
}
|
|
|
|
obj["args"] = std::move(args);
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(obj);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Final fallback: anything that gets past here is simply given a
|
|
|
|
// kind field of 'complex', and the only other field is the standard
|
|
|
|
// 'printable' representation.
|
|
|
|
|
|
|
|
assert(!I.isConcrete());
|
|
|
|
obj["kind"] = "complex";
|
2018-07-11 10:57:56 +02:00
|
|
|
return std::move(obj);
|
[TableGen] Add a general-purpose JSON backend.
The aim of this backend is to output everything TableGen knows about
the record set, similarly to the default -print-records backend. But
where -print-records produces output in TableGen's input syntax
(convenient for humans to read), this backend produces it as
structured JSON data, which is convenient for loading into standard
scripting languages such as Python, in order to extract information
from the data set in an automated way.
The output data contains a JSON representation of the variable
definitions in output 'def' records, and a few pieces of metadata such
as which of those definitions are tagged with the 'field' prefix and
which defs are derived from which classes. It doesn't dump out
absolutely every piece of knowledge it _could_ produce, such as type
information and complicated arithmetic operator nodes in abstract
superclasses; the main aim is to allow consumers of this JSON dump to
essentially act as new backends, and backends don't generally need to
depend on that kind of data.
The new backend is implemented as an EmitJSON() function similar to
all of llvm-tblgen's other EmitFoo functions, except that it lives in
lib/TableGen instead of utils/TableGen on the basis that I'm expecting
to add it to clang-tblgen too in a future patch.
To test it, I've written a Python script that loads the JSON output
and tests properties of it based on comments in the .td source - more
or less like FileCheck, except that the CHECK: lines have Python
expressions after them instead of textual pattern matches.
Reviewers: nhaehnle
Reviewed By: nhaehnle
Subscribers: arichardson, labath, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D46054
llvm-svn: 336771
2018-07-11 10:40:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void JSONEmitter::run(raw_ostream &OS) {
|
|
|
|
json::Object root;
|
|
|
|
|
|
|
|
root["!tablegen_json_version"] = 1;
|
|
|
|
|
|
|
|
// Prepare the arrays that will list the instances of every class.
|
|
|
|
// We mostly fill those in by iterating over the superclasses of
|
|
|
|
// each def, but we also want to ensure we store an empty list for a
|
|
|
|
// class with no instances at all, so we do a preliminary iteration
|
|
|
|
// over the classes, invoking std::map::operator[] to default-
|
|
|
|
// construct the array for each one.
|
|
|
|
std::map<std::string, json::Array> instance_lists;
|
|
|
|
for (const auto &C : Records.getClasses()) {
|
|
|
|
auto &Name = C.second->getNameInitAsString();
|
|
|
|
(void)instance_lists[Name];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Main iteration over the defs.
|
|
|
|
for (const auto &D : Records.getDefs()) {
|
|
|
|
auto &Name = D.second->getNameInitAsString();
|
|
|
|
auto &Def = *D.second;
|
|
|
|
|
|
|
|
json::Object obj;
|
|
|
|
json::Array fields;
|
|
|
|
|
|
|
|
for (const RecordVal &RV : Def.getValues()) {
|
|
|
|
if (!Def.isTemplateArg(RV.getNameInit())) {
|
|
|
|
auto Name = RV.getNameInitAsString();
|
|
|
|
if (RV.getPrefix())
|
|
|
|
fields.push_back(Name);
|
|
|
|
obj[Name] = translateInit(*RV.getValue());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
obj["!fields"] = std::move(fields);
|
|
|
|
|
|
|
|
json::Array superclasses;
|
|
|
|
for (const auto &SuperPair : Def.getSuperClasses())
|
|
|
|
superclasses.push_back(SuperPair.first->getNameInitAsString());
|
|
|
|
obj["!superclasses"] = std::move(superclasses);
|
|
|
|
|
|
|
|
obj["!name"] = Name;
|
|
|
|
obj["!anonymous"] = Def.isAnonymous();
|
|
|
|
|
|
|
|
root[Name] = std::move(obj);
|
|
|
|
|
|
|
|
// Add this def to the instance list for each of its superclasses.
|
|
|
|
for (const auto &SuperPair : Def.getSuperClasses()) {
|
|
|
|
auto SuperName = SuperPair.first->getNameInitAsString();
|
|
|
|
instance_lists[SuperName].push_back(Name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Make a JSON object from the std::map of instance lists.
|
|
|
|
json::Object instanceof;
|
|
|
|
for (auto kv: instance_lists)
|
|
|
|
instanceof[kv.first] = std::move(kv.second);
|
|
|
|
root["!instanceof"] = std::move(instanceof);
|
|
|
|
|
|
|
|
// Done. Write the output.
|
|
|
|
OS << json::Value(std::move(root)) << "\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
void EmitJSON(RecordKeeper &RK, raw_ostream &OS) { JSONEmitter(RK).run(OS); }
|
|
|
|
} // end namespace llvm
|