-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[clang] Refactor Builtins.def to be a tablegen file #68324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[clang] Refactor Builtins.def to be a tablegen file #68324
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My review may take a bit because GitHub is struggling to render the changes in Builtins.td.
However, I want to state up front just how incredibly excited I am for this refactoring. This will go a long ways towards letting us start to generate documentation for all of our builtins instead of manually having to add it to the LanguageExtensions.rst file (which is easy for folks to forget or ignore). So despite the extra complexity of using .td file, I think it's worth the complexity. Thank you for the work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm in favor of the changes in this patch, but precommit CI is currently failing with relevant failures that should be addressed.
@@ -0,0 +1,333 @@ | |||
//=- ClangDiagnosticsEmitter.cpp - Generate Clang diagnostics tables -*- C++ -*- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
//=- ClangDiagnosticsEmitter.cpp - Generate Clang diagnostics tables -*- C++ -*- | |
//=- ClangBuiltinsEmitter.cpp - Generate Clang builtins tables -*- C++ -*- |
May need to adjust formatting.
Prototype = Prototype.trim(); | ||
Prototype = Prototype.trim(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems suspicious, why two trims?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know. It's probably just a leftover.
f9e907f
to
da81d45
Compare
da81d45
to
e2c94d9
Compare
You can test this locally with the following command:git-clang-format --diff 54e2749609d7114f4a48f4146cddeecf76d935a4 ff03606e7d3b96d40909716b0a958f21c6b16fd2 -- clang/utils/TableGen/ClangBuiltinsEmitter.cpp clang/include/clang/AST/Expr.h clang/include/clang/Basic/Builtins.h clang/include/clang/Basic/TargetBuiltins.h clang/lib/AST/StmtPrinter.cpp clang/lib/Basic/Builtins.cpp clang/lib/Basic/Targets/BPF.cpp clang/lib/Sema/SemaChecking.cpp clang/lib/Sema/SemaExpr.cpp clang/test/Analysis/bstring.c clang/test/CodeGen/callback_pthread_create.c clang/utils/TableGen/MveEmitter.cpp clang/utils/TableGen/TableGen.cpp clang/utils/TableGen/TableGenBackends.h View the diff from clang-format here.diff --git a/clang/include/clang/Basic/Builtins.h b/clang/include/clang/Basic/Builtins.h
index f955d21169..b749ca4307 100644
--- a/clang/include/clang/Basic/Builtins.h
+++ b/clang/include/clang/Basic/Builtins.h
@@ -62,7 +62,7 @@ struct HeaderDesc {
namespace Builtin {
enum ID {
- NotBuiltin = 0, // This is not a builtin function.
+ NotBuiltin = 0, // This is not a builtin function.
#define BUILTIN(ID, TYPE, ATTRS) BI##ID,
#include "clang/Basic/Builtins.inc"
FirstTSBuiltin
diff --git a/clang/include/clang/Basic/TargetBuiltins.h b/clang/include/clang/Basic/TargetBuiltins.h
index d5de5a286f..df7fb19135 100644
--- a/clang/include/clang/Basic/TargetBuiltins.h
+++ b/clang/include/clang/Basic/TargetBuiltins.h
@@ -83,8 +83,8 @@ namespace clang {
namespace BPF {
enum {
LastTIBuiltin = clang::Builtin::FirstTSBuiltin - 1,
- #define BUILTIN(ID, TYPE, ATTRS) BI##ID,
- #include "clang/Basic/BuiltinsBPF.inc"
+#define BUILTIN(ID, TYPE, ATTRS) BI##ID,
+#include "clang/Basic/BuiltinsBPF.inc"
LastTSBuiltin
};
}
diff --git a/clang/utils/TableGen/TableGen.cpp b/clang/utils/TableGen/TableGen.cpp
index 6c1767d541..0a07ca1e85 100644
--- a/clang/utils/TableGen/TableGen.cpp
+++ b/clang/utils/TableGen/TableGen.cpp
@@ -282,11 +282,14 @@ cl::opt<ActionType> Action(
"Generate riscv_vector_builtin_cg.inc for clang"),
clEnumValN(GenRISCVVectorBuiltinSema, "gen-riscv-vector-builtin-sema",
"Generate riscv_vector_builtin_sema.inc for clang"),
- clEnumValN(GenRISCVSiFiveVectorBuiltins, "gen-riscv-sifive-vector-builtins",
+ clEnumValN(GenRISCVSiFiveVectorBuiltins,
+ "gen-riscv-sifive-vector-builtins",
"Generate riscv_sifive_vector_builtins.inc for clang"),
- clEnumValN(GenRISCVSiFiveVectorBuiltinCG, "gen-riscv-sifive-vector-builtin-codegen",
+ clEnumValN(GenRISCVSiFiveVectorBuiltinCG,
+ "gen-riscv-sifive-vector-builtin-codegen",
"Generate riscv_sifive_vector_builtin_cg.inc for clang"),
- clEnumValN(GenRISCVSiFiveVectorBuiltinSema, "gen-riscv-sifive-vector-builtin-sema",
+ clEnumValN(GenRISCVSiFiveVectorBuiltinSema,
+ "gen-riscv-sifive-vector-builtin-sema",
"Generate riscv_sifive_vector_builtin_sema.inc for clang"),
clEnumValN(GenAttrDocs, "gen-attr-docs",
"Generate attribute documentation"),
|
if (Op >= AO__opencl_atomic_load && Op <= AO__opencl_atomic_fetch_max) | ||
// FIXME: Allow grouping of builtins to be able to only check >= and <= | ||
if (Op >= AO__opencl_atomic_compare_exchange_strong && | ||
Op <= AO__opencl_atomic_store && Op != AO__opencl_atomic_init) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is adding the Op != AO__opencl_atomic_init
here acceptable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine for the moment, the FIXME comment clarifies what needs to be done to improve it in the future.
I would also be fine if you wanted to tackle it now (perhaps we should have some marking in the .td file to say "these should be grouped together as a range"?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather land this patch and improve things in follow-ups, since the refactoring is quite large and I'd like to avoid searching for added builtins again.
I've thought about adding something similar to the InGroup<SomeGroup>
we have for diagnostics, but I don't have a patch yet. Maybe something like InBuiltinRange<C11AtomicRange>
. That should make it trivial to teach tablegen to group the builtins, and maybe even generate functions to check whether a builtin is in a given range.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes LGTM, thank you for this awesome refactoring! Thank you!
Please wait to land until after we branch for Clang 18 and after CI has finish running (it'll be a race to see which happens first).
if (Op >= AO__opencl_atomic_load && Op <= AO__opencl_atomic_fetch_max) | ||
// FIXME: Allow grouping of builtins to be able to only check >= and <= | ||
if (Op >= AO__opencl_atomic_compare_exchange_strong && | ||
Op <= AO__opencl_atomic_store && Op != AO__opencl_atomic_init) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine for the moment, the FIXME comment clarifies what needs to be done to improve it in the future.
I would also be fine if you wanted to tackle it now (perhaps we should have some marking in the .td file to say "these should be grouped together as a range"?).
Hi, This patch changed
into
Something wrong there isn't it?
I haven't examined all builtins so no idea if there are more errors, I found this one when testing with -D_FORTIFY_SOURCE=2 |
@mikaelholmen Thanks. I've fixed the signature in e099e7b. |
Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've found few differences w.r.t. the previous builtins definition. If the change was intended to be a NFC then they might be considered issues.
let Prototype = "T()"; | ||
} | ||
|
||
def Inf : Builtin, FPMathWithF16F128Template { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before this change there was
BUILTIN(__builtin_inff16 , "x" , "ncE")
which means that the f16
variant was using _Float16
rather than __fp16
.
Is this change intended?
let Prototype = "T(T, int*)"; | ||
} | ||
|
||
def HugeVal : Builtin, FPMathWithF16F128Template { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before this change there was
BUILTIN(__builtin_huge_valf16, "x", "ncE")
which means that the f16
variant was using _Float16
rather than __fp16
.
Is this change intended?
Thank you for catching those; this was intended as an NFC change, so I think these are bugs. |
This commit addresses few differences between the `Builtins.def` file before the refactoring done in PR llvm#68324 and the currently generated `Builtins.inc` file.
This commit addresses few differences between the `Builtins.def` file before the refactoring done in PR llvm#68324 and the currently generated `Builtins.inc` file.
This commit addresses few differences between the `Builtins.def` file before the refactoring done in PR llvm#68324 and the currently generated `Builtins.inc` file.
@philnik777 - do you plan to use the TD definitions of the builtins anywhere else in the compiler? Francesco |
Not right now. I think the first thing to do is moving all the builtins to tablegen before we can make better use of it, which is going to take a while. |
I expect it will get used to generate documentation for builtins at some point in the future, similar to what we've done for attributes and command line options. |
This makes the builtins list quite a bit more verbose, but IMO this is a huge win in terms of readability.