Generate a .inc file that's included by .h and .cpp files,
instead of generating all C++ code in tablegen. The surrounding
C++ is easier to write in a C++ file, and it's consistent with
how the rest of llvm/ looks.
No intended behavior change.
Paths
| Differential D83636
omp: Make OMP tablegen more like all other tablegens. Needs ReviewPublic Authored by thakis on Jul 11 2020, 7:16 PM.
Details
Summary Generate a .inc file that's included by .h and .cpp files, No intended behavior change.
Diff Detail Event TimelineComment Actions While I agree that this reduce the code size it also split the code generation in two. We are also generating new code for Flang and probably it will be used by clang when we move the rest of the OMPKinds.def to TableGen (see https://reviews.llvm.org/D83326). I don't have strong opinion on this but looks like going back to the OMPKinds.def which we are trying to remove. Maybe @jdoerfert can review/comment this better. Comment Actions It puts the C++ code in C++ files :) I agree there are merits to both approaches, but this is the one used ~everywhere else in LLVM and clang, so if it's a wash it seems good to stay consistent with the rest of the codebase. Comment Actions
The C++ code is currently in a C++ files (OMP.cpp that replaces OMPConstants.cpp). I don't get this comment.
MLIR is using similar technics for the dialects code. As I said, I don't have a strong opinion on this but I would like @jdoerfert to have look at this before going forward if you don't mind. It feels just weird to me to re-generate macros to be used to generate code that we can generate directly. Comment Actions
We currently generate C++ code via tablegen, now we don't (generate as much C++ code but have the boilerplate manually written in OMP.cpp).
OK, I do not have much tablegen experience nor a strong opinion on this either way. To me, having macros for switches is not the problem since we generate the content via tablegen and not the macro cascade we used before. That makes the difference wrt. type safety and complex relationships. That said, it seems there are certain things we still generate as C++ and then include, e.g., the stuff guarded by GET_IS_ALLOWED_CLAUSE_FOR_DIRECTIVE_IMPL. So at the end we replace mostly switch code with generated macros, and use a manually written C++ boilerplate instead of generating it. Both seem sensible given the code size/complexity reduction. And then there is the fact that, if all things are equal, matching LLVM is for sure the preferred way.
Comment Actions
There are some limitation to this approach. For example how to you generate the new directive-clauses map used in Flang and that will probably make its way to Clang at some point. I'm just wondering if we are not removing some code for later introducing more complexity. But as I said before I'm happy with whatever is decided. Comment Actions @thakis Sorry this has been lying here for a while. I see the point of having this mixed "mode" where more complicated constructs are code gen inside the DirectiveEmitter and there is a way to do the simplest ones using macros and includes. Unfortunately, I think this patch is now behind the current version and OpenACC joined the frontend directory recently as it is under construction in Flang. If you think this is still valuable, I can offer to work on a new patch that cover both OpenMP and OpenACC and follow what you were trying to do here. @jdoerfert Any comments? Comment Actions
Not really, assuming there is nothing specifically new since my last comment here. Comment Actions I do think this is valuable. I was about to land it, but some change landed hours before I got the lg here and rebasing took me longer than 15 minutes, and I haven't had time to look at it again since then. If you could do something like this for ACC and OMP, I think that'd be great. As mentioned on the other review, having includes of "cpp.inc" files in .h files looks very unusual. Comment Actions
I agree with the inclusion of .cpp.inc inclusion inside .h file. Since then we have more code generated by tablegen and the file is meant to be included by both cpp or .h file depending on which section of code you include. I don't think we are very far from your solution with D92955 as I renamed the file. I'm happy to introduce the changes left in a further patch (after D92955) that would include ACC as well.
Revision Contents
Diff 277271 llvm/include/llvm/Frontend/Directive/DirectiveBase.td
llvm/include/llvm/Frontend/OpenMP/CMakeLists.txt
llvm/include/llvm/Frontend/OpenMP/OMP.h
llvm/include/llvm/Frontend/OpenMP/OMP.td
llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
llvm/lib/Frontend/OpenMP/CMakeLists.txt
llvm/lib/Frontend/OpenMP/OMP.cpp
llvm/test/TableGen/directive1.td
llvm/test/TableGen/directive2.td
llvm/utils/TableGen/DirectiveEmitter.cpp
llvm/utils/TableGen/TableGen.cpp
llvm/utils/TableGen/TableGenBackends.h
llvm/utils/gn/secondary/llvm/include/llvm/Frontend/OpenMP/BUILD.gn
llvm/utils/gn/secondary/llvm/lib/Frontend/OpenMP/BUILD.gn
|
file header missing.