2011-10-06 21:03:08 +08:00
|
|
|
//===- TableGen.cpp - Top-Level TableGen implementation for Clang ---------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08: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
|
2011-10-06 21:03:08 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains the main function for Clang's TableGen.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2019-11-26 09:15:47 +08:00
|
|
|
#include "TableGenBackends.h" // Declares all backends.
|
2019-10-26 09:38:07 +08:00
|
|
|
#include "ASTTableGen.h"
|
2011-10-06 21:03:08 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/PrettyStackTrace.h"
|
|
|
|
#include "llvm/Support/Signals.h"
|
|
|
|
#include "llvm/TableGen/Error.h"
|
|
|
|
#include "llvm/TableGen/Main.h"
|
|
|
|
#include "llvm/TableGen/Record.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
2012-06-13 13:12:41 +08:00
|
|
|
using namespace clang;
|
2011-10-06 21:03:08 +08:00
|
|
|
|
|
|
|
enum ActionType {
|
2018-08-22 17:20:39 +08:00
|
|
|
PrintRecords,
|
|
|
|
DumpJSON,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenClangAttrClasses,
|
2014-01-30 06:13:45 +08:00
|
|
|
GenClangAttrParserStringSwitches,
|
2017-04-18 22:33:39 +08:00
|
|
|
GenClangAttrSubjectMatchRulesParserStringSwitches,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenClangAttrImpl,
|
|
|
|
GenClangAttrList,
|
2017-04-18 22:33:39 +08:00
|
|
|
GenClangAttrSubjectMatchRuleList,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenClangAttrPCHRead,
|
|
|
|
GenClangAttrPCHWrite,
|
2014-03-31 21:14:44 +08:00
|
|
|
GenClangAttrHasAttributeImpl,
|
2013-01-25 00:46:58 +08:00
|
|
|
GenClangAttrSpellingListIndex,
|
2013-12-31 01:24:36 +08:00
|
|
|
GenClangAttrASTVisitor,
|
2012-01-21 06:37:06 +08:00
|
|
|
GenClangAttrTemplateInstantiate,
|
2012-03-07 08:12:16 +08:00
|
|
|
GenClangAttrParsedAttrList,
|
2013-09-10 07:33:17 +08:00
|
|
|
GenClangAttrParsedAttrImpl,
|
2012-03-07 08:12:16 +08:00
|
|
|
GenClangAttrParsedAttrKinds,
|
2019-01-12 03:16:01 +08:00
|
|
|
GenClangAttrTextNodeDump,
|
|
|
|
GenClangAttrNodeTraverse,
|
2019-12-14 10:52:16 +08:00
|
|
|
GenClangBasicReader,
|
|
|
|
GenClangBasicWriter,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenClangDiagsDefs,
|
|
|
|
GenClangDiagGroups,
|
|
|
|
GenClangDiagsIndexName,
|
2012-07-06 08:28:32 +08:00
|
|
|
GenClangCommentNodes,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenClangDeclNodes,
|
|
|
|
GenClangStmtNodes,
|
2019-10-02 07:13:03 +08:00
|
|
|
GenClangTypeNodes,
|
Abstract serialization: TableGen the (de)serialization code for Types.
The basic technical design here is that we have three levels
of readers and writers:
- At the lowest level, there's a `Basic{Reader,Writer}` that knows
how to emit the basic structures of the AST. CRTP allows this to
be metaprogrammed so that the client only needs to support a handful
of primitive types (e.g. `uint64_t` and `IdentifierInfo*`) and more
complicated "inline" structures such as `DeclarationName` can just
be emitted in terms of those primitives.
In Clang's binary-serialization code, these are
`ASTRecord{Reader,Writer}`. For now, a large number of basic
structures are still emitted explicitly by code on those classes
rather than by either TableGen or CRTP metaprogramming, but I
expect to move more of these over.
- In the middle, there's a `Property{Reader,Writer}` which is
responsible for processing the properties of a larger object. The
object-level reader/writer asks the property-level reader/writer to
project out a particular property, yielding a basic reader/writer
which will be used to read/write the property's value, like so:
```
propertyWriter.find("count").writeUInt32(node->getCount());
```
Clang's binary-serialization code ignores this level (it uses
the basic reader/writer as the property reader/writer and has the
projection methods just return `*this`) and simply relies on the
roperties being read/written in a stable order.
- At the highest level, there's an object reader/writer (e.g.
`Type{Reader,Writer}` which emits a logical object with properties.
Think of this as writing something like a JSON dictionary literal.
I haven't introduced support for bitcode abbreviations yet --- it
turns out that there aren't any operative abbreviations for types
besides the QualType one --- but I do have some ideas of how they
should work. At any rate, they'll be necessary in order to handle
statements.
I'm sorry for not disentangling the patches that added basic and type
reader/writers; I made some effort to, but I ran out of energy after
disentangling a number of other patches from the work.
Negligible impact on module size, time to build a set of about 20
fairly large modules, or time to read a few declarations out of them.
2019-12-14 10:54:44 +08:00
|
|
|
GenClangTypeReader,
|
|
|
|
GenClangTypeWriter,
|
[Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.
Reviewers: Bigcheese, jfb, rsmith
Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64146
llvm-svn: 371834
2019-09-13 17:46:16 +08:00
|
|
|
GenClangOpcodes,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenClangSACheckers,
|
2012-08-31 10:21:44 +08:00
|
|
|
GenClangCommentHTMLTags,
|
|
|
|
GenClangCommentHTMLTagsProperties,
|
2013-01-30 22:29:28 +08:00
|
|
|
GenClangCommentHTMLNamedCharacterReferences,
|
2012-09-11 04:32:42 +08:00
|
|
|
GenClangCommentCommandInfo,
|
2013-02-02 04:23:57 +08:00
|
|
|
GenClangCommentCommandList,
|
2019-06-03 17:39:11 +08:00
|
|
|
GenClangOpenCLBuiltins,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenArmNeon,
|
2018-01-20 07:11:18 +08:00
|
|
|
GenArmFP16,
|
2011-10-06 21:03:08 +08:00
|
|
|
GenArmNeonSema,
|
2014-02-17 23:27:10 +08:00
|
|
|
GenArmNeonTest,
|
[clang,ARM] Initial ACLE intrinsics for MVE.
This commit sets up the infrastructure for auto-generating <arm_mve.h>
and doing clang-side code generation for the builtins it relies on,
and demonstrates that it works by implementing a representative sample
of the ACLE intrinsics, more or less matching the ones introduced in
LLVM IR by D67158,D68699,D68700.
Like NEON, that header file will provide a set of vector types like
uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON,
the ACLE spec for <arm_mve.h> includes a polymorphism system, so that
you can write plain vaddq() and disambiguate by the vector types you
pass to it.
Unlike the corresponding NEON code, I've arranged to make every user-
facing ACLE intrinsic into a clang builtin, and implement all the code
generation inside clang. So <arm_mve.h> itself contains nothing but
typedefs and function declarations, with the latter all using the new
`__attribute__((__clang_builtin))` system to arrange that the user-
facing function names correspond to the right internal BuiltinIDs.
So the new MveEmitter tablegen system specifies the full sequence of
IRBuilder operations that each user-facing ACLE intrinsic should
translate into. Where possible, the ACLE intrinsics map to standard IR
operations such as vector-typed `add` and `fadd`; where no standard
representation exists, I call down to the sample IR intrinsics
introduced in an earlier commit.
Doing it like this means that you get the polymorphism for free just
by using __attribute__((overloadable)): the clang overload resolution
decides which function declaration is the relevant one, and _then_ its
BuiltinID is looked up, so by the time we're doing code generation,
that's all been resolved by the standard system. It also means that
you get really nice error messages if the user passes the wrong
combination of types: clang will show the declarations from the header
file and explain why each one doesn't match.
(The obvious alternative approach would be to have wrapper functions
in <arm_mve.h> which pass their arguments to the underlying builtins.
But that doesn't work in the case where one of the arguments has to be
a constant integer: the wrapper function can't pass the constantness
through. So you'd have to do that case using a macro instead, and then
use C11 `_Generic` to handle the polymorphism. Then you have to add
horrible workarounds because `_Generic` requires even the untaken
branches to type-check successfully, and //then// if the user gets the
types wrong, the error message is totally unreadable!)
Reviewers: dmgreen, miyuki, ostannard
Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67161
2019-09-02 22:50:50 +08:00
|
|
|
GenArmMveHeader,
|
|
|
|
GenArmMveBuiltinDef,
|
|
|
|
GenArmMveBuiltinSema,
|
|
|
|
GenArmMveBuiltinCG,
|
|
|
|
GenArmMveBuiltinAliases,
|
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE
Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intrinsics
(some of the intrinsics will be polymorphic and accept/return values
of MVE vector types).
Specifically the patch:
* Adds new tablegen backends -gen-arm-cde-builtin-def,
-gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema,
-gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on
existing MVE backends.
* Renames the '__clang_arm_mve_alias' attribute into
'__clang_arm_builtin_alias' (it will be used with CDE intrinsics as
well as MVE intrinsics)
* Implements semantic checks for the coprocessor argument of the CDE
intrinsics as well as the existing coprocessor intrinsics.
* Adds one CDE intrinsic __arm_cx1 to test the above changes
Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen
Reviewed By: simon_tatham
Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
|
|
|
GenArmCdeHeader,
|
|
|
|
GenArmCdeBuiltinDef,
|
|
|
|
GenArmCdeBuiltinSema,
|
|
|
|
GenArmCdeBuiltinCG,
|
|
|
|
GenArmCdeBuiltinAliases,
|
2016-09-12 13:58:29 +08:00
|
|
|
GenAttrDocs,
|
2017-01-25 03:39:46 +08:00
|
|
|
GenDiagDocs,
|
2017-04-18 22:33:39 +08:00
|
|
|
GenOptDocs,
|
2017-09-06 21:20:51 +08:00
|
|
|
GenDataCollectors,
|
2017-04-18 22:33:39 +08:00
|
|
|
GenTestPragmaAttributeSupportedAttributes
|
2011-10-06 21:03:08 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
namespace {
|
2013-08-17 00:46:27 +08:00
|
|
|
cl::opt<ActionType> Action(
|
|
|
|
cl::desc("Action to perform:"),
|
|
|
|
cl::values(
|
2018-08-22 17:20:39 +08:00
|
|
|
clEnumValN(PrintRecords, "print-records",
|
|
|
|
"Print all records to stdout (default)"),
|
|
|
|
clEnumValN(DumpJSON, "dump-json",
|
|
|
|
"Dump all records as machine-readable JSON"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangAttrClasses, "gen-clang-attr-classes",
|
|
|
|
"Generate clang attribute clases"),
|
2014-01-30 06:13:45 +08:00
|
|
|
clEnumValN(GenClangAttrParserStringSwitches,
|
|
|
|
"gen-clang-attr-parser-string-switches",
|
|
|
|
"Generate all parser-related attribute string switches"),
|
2017-04-18 22:33:39 +08:00
|
|
|
clEnumValN(GenClangAttrSubjectMatchRulesParserStringSwitches,
|
|
|
|
"gen-clang-attr-subject-match-rules-parser-string-switches",
|
|
|
|
"Generate all parser-related attribute subject match rule"
|
|
|
|
"string switches"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangAttrImpl, "gen-clang-attr-impl",
|
|
|
|
"Generate clang attribute implementations"),
|
|
|
|
clEnumValN(GenClangAttrList, "gen-clang-attr-list",
|
|
|
|
"Generate a clang attribute list"),
|
2017-04-18 22:33:39 +08:00
|
|
|
clEnumValN(GenClangAttrSubjectMatchRuleList,
|
|
|
|
"gen-clang-attr-subject-match-rule-list",
|
|
|
|
"Generate a clang attribute subject match rule list"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangAttrPCHRead, "gen-clang-attr-pch-read",
|
|
|
|
"Generate clang PCH attribute reader"),
|
|
|
|
clEnumValN(GenClangAttrPCHWrite, "gen-clang-attr-pch-write",
|
|
|
|
"Generate clang PCH attribute writer"),
|
2014-03-31 21:14:44 +08:00
|
|
|
clEnumValN(GenClangAttrHasAttributeImpl,
|
|
|
|
"gen-clang-attr-has-attribute-impl",
|
2013-08-17 00:46:27 +08:00
|
|
|
"Generate a clang attribute spelling list"),
|
|
|
|
clEnumValN(GenClangAttrSpellingListIndex,
|
|
|
|
"gen-clang-attr-spelling-index",
|
|
|
|
"Generate a clang attribute spelling index"),
|
2017-04-18 22:33:39 +08:00
|
|
|
clEnumValN(GenClangAttrASTVisitor, "gen-clang-attr-ast-visitor",
|
2013-12-31 01:24:36 +08:00
|
|
|
"Generate a recursive AST visitor for clang attributes"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangAttrTemplateInstantiate,
|
|
|
|
"gen-clang-attr-template-instantiate",
|
|
|
|
"Generate a clang template instantiate code"),
|
2013-10-24 09:07:54 +08:00
|
|
|
clEnumValN(GenClangAttrParsedAttrList,
|
|
|
|
"gen-clang-attr-parsed-attr-list",
|
|
|
|
"Generate a clang parsed attribute list"),
|
|
|
|
clEnumValN(GenClangAttrParsedAttrImpl,
|
|
|
|
"gen-clang-attr-parsed-attr-impl",
|
|
|
|
"Generate the clang parsed attribute helpers"),
|
|
|
|
clEnumValN(GenClangAttrParsedAttrKinds,
|
|
|
|
"gen-clang-attr-parsed-attr-kinds",
|
|
|
|
"Generate a clang parsed attribute kinds"),
|
2019-01-12 03:16:01 +08:00
|
|
|
clEnumValN(GenClangAttrTextNodeDump, "gen-clang-attr-text-node-dump",
|
|
|
|
"Generate clang attribute text node dumper"),
|
|
|
|
clEnumValN(GenClangAttrNodeTraverse, "gen-clang-attr-node-traverse",
|
|
|
|
"Generate clang attribute traverser"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangDiagsDefs, "gen-clang-diags-defs",
|
|
|
|
"Generate Clang diagnostics definitions"),
|
|
|
|
clEnumValN(GenClangDiagGroups, "gen-clang-diag-groups",
|
|
|
|
"Generate Clang diagnostic groups"),
|
|
|
|
clEnumValN(GenClangDiagsIndexName, "gen-clang-diags-index-name",
|
|
|
|
"Generate Clang diagnostic name index"),
|
2019-12-14 10:52:16 +08:00
|
|
|
clEnumValN(GenClangBasicReader, "gen-clang-basic-reader",
|
|
|
|
"Generate Clang BasicReader classes"),
|
|
|
|
clEnumValN(GenClangBasicWriter, "gen-clang-basic-writer",
|
|
|
|
"Generate Clang BasicWriter classes"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangCommentNodes, "gen-clang-comment-nodes",
|
|
|
|
"Generate Clang AST comment nodes"),
|
|
|
|
clEnumValN(GenClangDeclNodes, "gen-clang-decl-nodes",
|
|
|
|
"Generate Clang AST declaration nodes"),
|
|
|
|
clEnumValN(GenClangStmtNodes, "gen-clang-stmt-nodes",
|
|
|
|
"Generate Clang AST statement nodes"),
|
2019-10-02 07:13:03 +08:00
|
|
|
clEnumValN(GenClangTypeNodes, "gen-clang-type-nodes",
|
|
|
|
"Generate Clang AST type nodes"),
|
Abstract serialization: TableGen the (de)serialization code for Types.
The basic technical design here is that we have three levels
of readers and writers:
- At the lowest level, there's a `Basic{Reader,Writer}` that knows
how to emit the basic structures of the AST. CRTP allows this to
be metaprogrammed so that the client only needs to support a handful
of primitive types (e.g. `uint64_t` and `IdentifierInfo*`) and more
complicated "inline" structures such as `DeclarationName` can just
be emitted in terms of those primitives.
In Clang's binary-serialization code, these are
`ASTRecord{Reader,Writer}`. For now, a large number of basic
structures are still emitted explicitly by code on those classes
rather than by either TableGen or CRTP metaprogramming, but I
expect to move more of these over.
- In the middle, there's a `Property{Reader,Writer}` which is
responsible for processing the properties of a larger object. The
object-level reader/writer asks the property-level reader/writer to
project out a particular property, yielding a basic reader/writer
which will be used to read/write the property's value, like so:
```
propertyWriter.find("count").writeUInt32(node->getCount());
```
Clang's binary-serialization code ignores this level (it uses
the basic reader/writer as the property reader/writer and has the
projection methods just return `*this`) and simply relies on the
roperties being read/written in a stable order.
- At the highest level, there's an object reader/writer (e.g.
`Type{Reader,Writer}` which emits a logical object with properties.
Think of this as writing something like a JSON dictionary literal.
I haven't introduced support for bitcode abbreviations yet --- it
turns out that there aren't any operative abbreviations for types
besides the QualType one --- but I do have some ideas of how they
should work. At any rate, they'll be necessary in order to handle
statements.
I'm sorry for not disentangling the patches that added basic and type
reader/writers; I made some effort to, but I ran out of energy after
disentangling a number of other patches from the work.
Negligible impact on module size, time to build a set of about 20
fairly large modules, or time to read a few declarations out of them.
2019-12-14 10:54:44 +08:00
|
|
|
clEnumValN(GenClangTypeReader, "gen-clang-type-reader",
|
|
|
|
"Generate Clang AbstractTypeReader class"),
|
|
|
|
clEnumValN(GenClangTypeWriter, "gen-clang-type-writer",
|
|
|
|
"Generate Clang AbstractTypeWriter class"),
|
[Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.
Reviewers: Bigcheese, jfb, rsmith
Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64146
llvm-svn: 371834
2019-09-13 17:46:16 +08:00
|
|
|
clEnumValN(GenClangOpcodes, "gen-clang-opcodes",
|
|
|
|
"Generate Clang constexpr interpreter opcodes"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenClangSACheckers, "gen-clang-sa-checkers",
|
|
|
|
"Generate Clang Static Analyzer checkers"),
|
|
|
|
clEnumValN(GenClangCommentHTMLTags, "gen-clang-comment-html-tags",
|
|
|
|
"Generate efficient matchers for HTML tag "
|
|
|
|
"names that are used in documentation comments"),
|
|
|
|
clEnumValN(GenClangCommentHTMLTagsProperties,
|
|
|
|
"gen-clang-comment-html-tags-properties",
|
|
|
|
"Generate efficient matchers for HTML tag "
|
|
|
|
"properties"),
|
|
|
|
clEnumValN(GenClangCommentHTMLNamedCharacterReferences,
|
|
|
|
"gen-clang-comment-html-named-character-references",
|
|
|
|
"Generate function to translate named character "
|
|
|
|
"references to UTF-8 sequences"),
|
|
|
|
clEnumValN(GenClangCommentCommandInfo, "gen-clang-comment-command-info",
|
|
|
|
"Generate command properties for commands that "
|
|
|
|
"are used in documentation comments"),
|
|
|
|
clEnumValN(GenClangCommentCommandList, "gen-clang-comment-command-list",
|
|
|
|
"Generate list of commands that are used in "
|
|
|
|
"documentation comments"),
|
2019-06-03 17:39:11 +08:00
|
|
|
clEnumValN(GenClangOpenCLBuiltins, "gen-clang-opencl-builtins",
|
|
|
|
"Generate OpenCL builtin declaration handlers"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenArmNeon, "gen-arm-neon", "Generate arm_neon.h for clang"),
|
2018-01-20 07:11:18 +08:00
|
|
|
clEnumValN(GenArmFP16, "gen-arm-fp16", "Generate arm_fp16.h for clang"),
|
2013-08-17 00:46:27 +08:00
|
|
|
clEnumValN(GenArmNeonSema, "gen-arm-neon-sema",
|
|
|
|
"Generate ARM NEON sema support for clang"),
|
|
|
|
clEnumValN(GenArmNeonTest, "gen-arm-neon-test",
|
|
|
|
"Generate ARM NEON tests for clang"),
|
[clang,ARM] Initial ACLE intrinsics for MVE.
This commit sets up the infrastructure for auto-generating <arm_mve.h>
and doing clang-side code generation for the builtins it relies on,
and demonstrates that it works by implementing a representative sample
of the ACLE intrinsics, more or less matching the ones introduced in
LLVM IR by D67158,D68699,D68700.
Like NEON, that header file will provide a set of vector types like
uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON,
the ACLE spec for <arm_mve.h> includes a polymorphism system, so that
you can write plain vaddq() and disambiguate by the vector types you
pass to it.
Unlike the corresponding NEON code, I've arranged to make every user-
facing ACLE intrinsic into a clang builtin, and implement all the code
generation inside clang. So <arm_mve.h> itself contains nothing but
typedefs and function declarations, with the latter all using the new
`__attribute__((__clang_builtin))` system to arrange that the user-
facing function names correspond to the right internal BuiltinIDs.
So the new MveEmitter tablegen system specifies the full sequence of
IRBuilder operations that each user-facing ACLE intrinsic should
translate into. Where possible, the ACLE intrinsics map to standard IR
operations such as vector-typed `add` and `fadd`; where no standard
representation exists, I call down to the sample IR intrinsics
introduced in an earlier commit.
Doing it like this means that you get the polymorphism for free just
by using __attribute__((overloadable)): the clang overload resolution
decides which function declaration is the relevant one, and _then_ its
BuiltinID is looked up, so by the time we're doing code generation,
that's all been resolved by the standard system. It also means that
you get really nice error messages if the user passes the wrong
combination of types: clang will show the declarations from the header
file and explain why each one doesn't match.
(The obvious alternative approach would be to have wrapper functions
in <arm_mve.h> which pass their arguments to the underlying builtins.
But that doesn't work in the case where one of the arguments has to be
a constant integer: the wrapper function can't pass the constantness
through. So you'd have to do that case using a macro instead, and then
use C11 `_Generic` to handle the polymorphism. Then you have to add
horrible workarounds because `_Generic` requires even the untaken
branches to type-check successfully, and //then// if the user gets the
types wrong, the error message is totally unreadable!)
Reviewers: dmgreen, miyuki, ostannard
Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67161
2019-09-02 22:50:50 +08:00
|
|
|
clEnumValN(GenArmMveHeader, "gen-arm-mve-header",
|
|
|
|
"Generate arm_mve.h for clang"),
|
|
|
|
clEnumValN(GenArmMveBuiltinDef, "gen-arm-mve-builtin-def",
|
|
|
|
"Generate ARM MVE builtin definitions for clang"),
|
|
|
|
clEnumValN(GenArmMveBuiltinSema, "gen-arm-mve-builtin-sema",
|
|
|
|
"Generate ARM MVE builtin sema checks for clang"),
|
|
|
|
clEnumValN(GenArmMveBuiltinCG, "gen-arm-mve-builtin-codegen",
|
|
|
|
"Generate ARM MVE builtin code-generator for clang"),
|
|
|
|
clEnumValN(GenArmMveBuiltinAliases, "gen-arm-mve-builtin-aliases",
|
|
|
|
"Generate list of valid ARM MVE builtin aliases for clang"),
|
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE
Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intrinsics
(some of the intrinsics will be polymorphic and accept/return values
of MVE vector types).
Specifically the patch:
* Adds new tablegen backends -gen-arm-cde-builtin-def,
-gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema,
-gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on
existing MVE backends.
* Renames the '__clang_arm_mve_alias' attribute into
'__clang_arm_builtin_alias' (it will be used with CDE intrinsics as
well as MVE intrinsics)
* Implements semantic checks for the coprocessor argument of the CDE
intrinsics as well as the existing coprocessor intrinsics.
* Adds one CDE intrinsic __arm_cx1 to test the above changes
Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen
Reviewed By: simon_tatham
Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
|
|
|
clEnumValN(GenArmCdeHeader, "gen-arm-cde-header",
|
|
|
|
"Generate arm_cde.h for clang"),
|
|
|
|
clEnumValN(GenArmCdeBuiltinDef, "gen-arm-cde-builtin-def",
|
|
|
|
"Generate ARM CDE builtin definitions for clang"),
|
|
|
|
clEnumValN(GenArmCdeBuiltinSema, "gen-arm-cde-builtin-sema",
|
|
|
|
"Generate ARM CDE builtin sema checks for clang"),
|
|
|
|
clEnumValN(GenArmCdeBuiltinCG, "gen-arm-cde-builtin-codegen",
|
|
|
|
"Generate ARM CDE builtin code-generator for clang"),
|
|
|
|
clEnumValN(GenArmCdeBuiltinAliases, "gen-arm-cde-builtin-aliases",
|
|
|
|
"Generate list of valid ARM CDE builtin aliases for clang"),
|
2014-02-17 23:27:10 +08:00
|
|
|
clEnumValN(GenAttrDocs, "gen-attr-docs",
|
|
|
|
"Generate attribute documentation"),
|
2016-09-12 13:58:29 +08:00
|
|
|
clEnumValN(GenDiagDocs, "gen-diag-docs",
|
2017-01-25 03:39:46 +08:00
|
|
|
"Generate diagnostic documentation"),
|
2017-04-18 22:33:39 +08:00
|
|
|
clEnumValN(GenOptDocs, "gen-opt-docs", "Generate option documentation"),
|
2017-09-06 21:20:51 +08:00
|
|
|
clEnumValN(GenDataCollectors, "gen-clang-data-collectors",
|
|
|
|
"Generate data collectors for AST nodes"),
|
2017-04-18 22:33:39 +08:00
|
|
|
clEnumValN(GenTestPragmaAttributeSupportedAttributes,
|
|
|
|
"gen-clang-test-pragma-attribute-supported-attributes",
|
|
|
|
"Generate a list of attributes supported by #pragma clang "
|
|
|
|
"attribute for testing purposes")));
|
2011-10-06 21:03:08 +08:00
|
|
|
|
2013-08-17 00:46:27 +08:00
|
|
|
cl::opt<std::string>
|
|
|
|
ClangComponent("clang-component",
|
|
|
|
cl::desc("Only use warnings from specified component"),
|
|
|
|
cl::value_desc("component"), cl::Hidden);
|
2011-10-06 21:03:08 +08:00
|
|
|
|
2012-10-04 05:29:30 +08:00
|
|
|
bool ClangTableGenMain(raw_ostream &OS, RecordKeeper &Records) {
|
|
|
|
switch (Action) {
|
2018-08-22 17:20:39 +08:00
|
|
|
case PrintRecords:
|
|
|
|
OS << Records; // No argument, dump all contents
|
|
|
|
break;
|
|
|
|
case DumpJSON:
|
|
|
|
EmitJSON(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangAttrClasses:
|
|
|
|
EmitClangAttrClass(Records, OS);
|
|
|
|
break;
|
2014-01-30 06:13:45 +08:00
|
|
|
case GenClangAttrParserStringSwitches:
|
|
|
|
EmitClangAttrParserStringSwitches(Records, OS);
|
2013-11-04 20:55:56 +08:00
|
|
|
break;
|
2017-04-18 22:33:39 +08:00
|
|
|
case GenClangAttrSubjectMatchRulesParserStringSwitches:
|
|
|
|
EmitClangAttrSubjectMatchRulesParserStringSwitches(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangAttrImpl:
|
|
|
|
EmitClangAttrImpl(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangAttrList:
|
|
|
|
EmitClangAttrList(Records, OS);
|
|
|
|
break;
|
2017-04-18 22:33:39 +08:00
|
|
|
case GenClangAttrSubjectMatchRuleList:
|
|
|
|
EmitClangAttrSubjectMatchRuleList(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangAttrPCHRead:
|
|
|
|
EmitClangAttrPCHRead(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangAttrPCHWrite:
|
|
|
|
EmitClangAttrPCHWrite(Records, OS);
|
|
|
|
break;
|
2014-03-31 21:14:44 +08:00
|
|
|
case GenClangAttrHasAttributeImpl:
|
|
|
|
EmitClangAttrHasAttrImpl(Records, OS);
|
2012-10-04 05:29:30 +08:00
|
|
|
break;
|
2013-01-25 00:46:58 +08:00
|
|
|
case GenClangAttrSpellingListIndex:
|
|
|
|
EmitClangAttrSpellingListIndex(Records, OS);
|
|
|
|
break;
|
2013-12-31 01:24:36 +08:00
|
|
|
case GenClangAttrASTVisitor:
|
|
|
|
EmitClangAttrASTVisitor(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangAttrTemplateInstantiate:
|
|
|
|
EmitClangAttrTemplateInstantiate(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangAttrParsedAttrList:
|
|
|
|
EmitClangAttrParsedAttrList(Records, OS);
|
|
|
|
break;
|
2013-09-10 07:33:17 +08:00
|
|
|
case GenClangAttrParsedAttrImpl:
|
|
|
|
EmitClangAttrParsedAttrImpl(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangAttrParsedAttrKinds:
|
|
|
|
EmitClangAttrParsedAttrKinds(Records, OS);
|
|
|
|
break;
|
2019-01-12 03:16:01 +08:00
|
|
|
case GenClangAttrTextNodeDump:
|
|
|
|
EmitClangAttrTextNodeDump(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangAttrNodeTraverse:
|
|
|
|
EmitClangAttrNodeTraverse(Records, OS);
|
2013-01-08 01:53:08 +08:00
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangDiagsDefs:
|
|
|
|
EmitClangDiagsDefs(Records, OS, ClangComponent);
|
|
|
|
break;
|
|
|
|
case GenClangDiagGroups:
|
|
|
|
EmitClangDiagGroups(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangDiagsIndexName:
|
|
|
|
EmitClangDiagsIndexName(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangCommentNodes:
|
2019-10-26 07:28:03 +08:00
|
|
|
EmitClangASTNodes(Records, OS, CommentNodeClassName, "");
|
2012-10-04 05:29:30 +08:00
|
|
|
break;
|
|
|
|
case GenClangDeclNodes:
|
2019-10-26 07:28:03 +08:00
|
|
|
EmitClangASTNodes(Records, OS, DeclNodeClassName, "Decl");
|
2012-10-04 05:29:30 +08:00
|
|
|
EmitClangDeclContext(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangStmtNodes:
|
2019-10-26 07:28:03 +08:00
|
|
|
EmitClangASTNodes(Records, OS, StmtNodeClassName, "");
|
2012-10-04 05:29:30 +08:00
|
|
|
break;
|
2019-10-02 07:13:03 +08:00
|
|
|
case GenClangTypeNodes:
|
|
|
|
EmitClangTypeNodes(Records, OS);
|
|
|
|
break;
|
Abstract serialization: TableGen the (de)serialization code for Types.
The basic technical design here is that we have three levels
of readers and writers:
- At the lowest level, there's a `Basic{Reader,Writer}` that knows
how to emit the basic structures of the AST. CRTP allows this to
be metaprogrammed so that the client only needs to support a handful
of primitive types (e.g. `uint64_t` and `IdentifierInfo*`) and more
complicated "inline" structures such as `DeclarationName` can just
be emitted in terms of those primitives.
In Clang's binary-serialization code, these are
`ASTRecord{Reader,Writer}`. For now, a large number of basic
structures are still emitted explicitly by code on those classes
rather than by either TableGen or CRTP metaprogramming, but I
expect to move more of these over.
- In the middle, there's a `Property{Reader,Writer}` which is
responsible for processing the properties of a larger object. The
object-level reader/writer asks the property-level reader/writer to
project out a particular property, yielding a basic reader/writer
which will be used to read/write the property's value, like so:
```
propertyWriter.find("count").writeUInt32(node->getCount());
```
Clang's binary-serialization code ignores this level (it uses
the basic reader/writer as the property reader/writer and has the
projection methods just return `*this`) and simply relies on the
roperties being read/written in a stable order.
- At the highest level, there's an object reader/writer (e.g.
`Type{Reader,Writer}` which emits a logical object with properties.
Think of this as writing something like a JSON dictionary literal.
I haven't introduced support for bitcode abbreviations yet --- it
turns out that there aren't any operative abbreviations for types
besides the QualType one --- but I do have some ideas of how they
should work. At any rate, they'll be necessary in order to handle
statements.
I'm sorry for not disentangling the patches that added basic and type
reader/writers; I made some effort to, but I ran out of energy after
disentangling a number of other patches from the work.
Negligible impact on module size, time to build a set of about 20
fairly large modules, or time to read a few declarations out of them.
2019-12-14 10:54:44 +08:00
|
|
|
case GenClangTypeReader:
|
|
|
|
EmitClangTypeReader(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangTypeWriter:
|
|
|
|
EmitClangTypeWriter(Records, OS);
|
|
|
|
break;
|
2019-12-14 10:52:16 +08:00
|
|
|
case GenClangBasicReader:
|
|
|
|
EmitClangBasicReader(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangBasicWriter:
|
|
|
|
EmitClangBasicWriter(Records, OS);
|
|
|
|
break;
|
[Clang Interpreter] Initial patch for the constexpr interpreter
Summary:
This patch introduces the skeleton of the constexpr interpreter,
capable of evaluating a simple constexpr functions consisting of
if statements. The interpreter is described in more detail in the
RFC. Further patches will add more features.
Reviewers: Bigcheese, jfb, rsmith
Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64146
llvm-svn: 371834
2019-09-13 17:46:16 +08:00
|
|
|
case GenClangOpcodes:
|
|
|
|
EmitClangOpcodes(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangSACheckers:
|
|
|
|
EmitClangSACheckers(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangCommentHTMLTags:
|
|
|
|
EmitClangCommentHTMLTags(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenClangCommentHTMLTagsProperties:
|
|
|
|
EmitClangCommentHTMLTagsProperties(Records, OS);
|
|
|
|
break;
|
2013-01-30 22:29:28 +08:00
|
|
|
case GenClangCommentHTMLNamedCharacterReferences:
|
|
|
|
EmitClangCommentHTMLNamedCharacterReferences(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenClangCommentCommandInfo:
|
|
|
|
EmitClangCommentCommandInfo(Records, OS);
|
|
|
|
break;
|
2013-02-02 04:23:57 +08:00
|
|
|
case GenClangCommentCommandList:
|
|
|
|
EmitClangCommentCommandList(Records, OS);
|
|
|
|
break;
|
2019-06-03 17:39:11 +08:00
|
|
|
case GenClangOpenCLBuiltins:
|
|
|
|
EmitClangOpenCLBuiltins(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenArmNeon:
|
|
|
|
EmitNeon(Records, OS);
|
|
|
|
break;
|
2018-01-20 07:11:18 +08:00
|
|
|
case GenArmFP16:
|
|
|
|
EmitFP16(Records, OS);
|
|
|
|
break;
|
2012-10-04 05:29:30 +08:00
|
|
|
case GenArmNeonSema:
|
|
|
|
EmitNeonSema(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmNeonTest:
|
|
|
|
EmitNeonTest(Records, OS);
|
|
|
|
break;
|
[clang,ARM] Initial ACLE intrinsics for MVE.
This commit sets up the infrastructure for auto-generating <arm_mve.h>
and doing clang-side code generation for the builtins it relies on,
and demonstrates that it works by implementing a representative sample
of the ACLE intrinsics, more or less matching the ones introduced in
LLVM IR by D67158,D68699,D68700.
Like NEON, that header file will provide a set of vector types like
uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON,
the ACLE spec for <arm_mve.h> includes a polymorphism system, so that
you can write plain vaddq() and disambiguate by the vector types you
pass to it.
Unlike the corresponding NEON code, I've arranged to make every user-
facing ACLE intrinsic into a clang builtin, and implement all the code
generation inside clang. So <arm_mve.h> itself contains nothing but
typedefs and function declarations, with the latter all using the new
`__attribute__((__clang_builtin))` system to arrange that the user-
facing function names correspond to the right internal BuiltinIDs.
So the new MveEmitter tablegen system specifies the full sequence of
IRBuilder operations that each user-facing ACLE intrinsic should
translate into. Where possible, the ACLE intrinsics map to standard IR
operations such as vector-typed `add` and `fadd`; where no standard
representation exists, I call down to the sample IR intrinsics
introduced in an earlier commit.
Doing it like this means that you get the polymorphism for free just
by using __attribute__((overloadable)): the clang overload resolution
decides which function declaration is the relevant one, and _then_ its
BuiltinID is looked up, so by the time we're doing code generation,
that's all been resolved by the standard system. It also means that
you get really nice error messages if the user passes the wrong
combination of types: clang will show the declarations from the header
file and explain why each one doesn't match.
(The obvious alternative approach would be to have wrapper functions
in <arm_mve.h> which pass their arguments to the underlying builtins.
But that doesn't work in the case where one of the arguments has to be
a constant integer: the wrapper function can't pass the constantness
through. So you'd have to do that case using a macro instead, and then
use C11 `_Generic` to handle the polymorphism. Then you have to add
horrible workarounds because `_Generic` requires even the untaken
branches to type-check successfully, and //then// if the user gets the
types wrong, the error message is totally unreadable!)
Reviewers: dmgreen, miyuki, ostannard
Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67161
2019-09-02 22:50:50 +08:00
|
|
|
case GenArmMveHeader:
|
|
|
|
EmitMveHeader(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmMveBuiltinDef:
|
|
|
|
EmitMveBuiltinDef(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmMveBuiltinSema:
|
|
|
|
EmitMveBuiltinSema(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmMveBuiltinCG:
|
|
|
|
EmitMveBuiltinCG(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmMveBuiltinAliases:
|
|
|
|
EmitMveBuiltinAliases(Records, OS);
|
|
|
|
break;
|
[ARM,CDE] Generalize MVE intrinsics infrastructure to support CDE
Summary:
This patch generalizes the existing code to support CDE intrinsics
which will share some properties with existing MVE intrinsics
(some of the intrinsics will be polymorphic and accept/return values
of MVE vector types).
Specifically the patch:
* Adds new tablegen backends -gen-arm-cde-builtin-def,
-gen-arm-cde-builtin-codegen, -gen-arm-cde-builtin-sema,
-gen-arm-cde-builtin-aliases, -gen-arm-cde-builtin-header based on
existing MVE backends.
* Renames the '__clang_arm_mve_alias' attribute into
'__clang_arm_builtin_alias' (it will be used with CDE intrinsics as
well as MVE intrinsics)
* Implements semantic checks for the coprocessor argument of the CDE
intrinsics as well as the existing coprocessor intrinsics.
* Adds one CDE intrinsic __arm_cx1 to test the above changes
Reviewers: simon_tatham, MarkMurrayARM, ostannard, dmgreen
Reviewed By: simon_tatham
Subscribers: sdesmalen, mgorny, kristof.beyls, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D75850
2020-03-10 22:01:42 +08:00
|
|
|
case GenArmCdeHeader:
|
|
|
|
EmitCdeHeader(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmCdeBuiltinDef:
|
|
|
|
EmitCdeBuiltinDef(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmCdeBuiltinSema:
|
|
|
|
EmitCdeBuiltinSema(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmCdeBuiltinCG:
|
|
|
|
EmitCdeBuiltinCG(Records, OS);
|
|
|
|
break;
|
|
|
|
case GenArmCdeBuiltinAliases:
|
|
|
|
EmitCdeBuiltinAliases(Records, OS);
|
|
|
|
break;
|
2014-02-17 23:27:10 +08:00
|
|
|
case GenAttrDocs:
|
|
|
|
EmitClangAttrDocs(Records, OS);
|
|
|
|
break;
|
2016-09-12 13:58:29 +08:00
|
|
|
case GenDiagDocs:
|
|
|
|
EmitClangDiagDocs(Records, OS);
|
|
|
|
break;
|
2017-01-25 03:39:46 +08:00
|
|
|
case GenOptDocs:
|
|
|
|
EmitClangOptDocs(Records, OS);
|
|
|
|
break;
|
2017-09-06 21:20:51 +08:00
|
|
|
case GenDataCollectors:
|
|
|
|
EmitClangDataCollectors(Records, OS);
|
|
|
|
break;
|
2017-04-18 22:33:39 +08:00
|
|
|
case GenTestPragmaAttributeSupportedAttributes:
|
|
|
|
EmitTestPragmaAttributeSupportedAttributes(Records, OS);
|
|
|
|
break;
|
2011-10-06 21:03:08 +08:00
|
|
|
}
|
2012-10-04 05:29:30 +08:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2015-06-23 07:07:51 +08:00
|
|
|
}
|
2011-10-06 21:03:08 +08:00
|
|
|
|
|
|
|
int main(int argc, char **argv) {
|
2019-11-26 10:06:56 +08:00
|
|
|
sys::PrintStackTraceOnErrorSignal(argv[0]);
|
|
|
|
PrettyStackTraceProgram X(argc, argv);
|
2011-10-06 21:03:08 +08:00
|
|
|
cl::ParseCommandLineOptions(argc, argv);
|
|
|
|
|
2016-01-04 12:51:46 +08:00
|
|
|
llvm_shutdown_obj Y;
|
|
|
|
|
2012-10-04 05:29:30 +08:00
|
|
|
return TableGenMain(argv[0], &ClangTableGenMain);
|
2011-10-06 21:03:08 +08:00
|
|
|
}
|
2014-01-10 16:05:42 +08:00
|
|
|
|
2014-01-15 15:59:37 +08:00
|
|
|
#ifdef __has_feature
|
|
|
|
#if __has_feature(address_sanitizer)
|
|
|
|
#include <sanitizer/lsan_interface.h>
|
2014-01-10 16:05:42 +08:00
|
|
|
// Disable LeakSanitizer for this binary as it has too many leaks that are not
|
2014-01-15 15:59:37 +08:00
|
|
|
// very interesting to fix. See compiler-rt/include/sanitizer/lsan_interface.h .
|
|
|
|
int __lsan_is_turned_off() { return 1; }
|
|
|
|
#endif // __has_feature(address_sanitizer)
|
|
|
|
#endif // defined(__has_feature)
|