This is an archive of the discontinued LLVM Phabricator instance.

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,
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.

Diff Detail

Event Timeline

thakis created this revision.Jul 11 2020, 7:16 PM
Herald added a project: Restricted Project. · View Herald Transcript

As discussed a while ago in D81736. It's about half as much code.

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.

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.

It puts the C++ code in C++ files :)

The C++ code is currently in a C++ files (OMP.cpp that replaces OMPConstants.cpp). I don't get this comment.

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.

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.

It puts the C++ code in C++ files :)

The C++ code is currently in a C++ files (OMP.cpp that replaces OMPConstants.cpp). I don't get this comment.

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).

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.

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.

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.

llvm/include/llvm/Frontend/OpenMP/OMP.h
1

file header missing.

53

Wrong guard naem?

It puts the C++ code in C++ files :)

The C++ code is currently in a C++ files (OMP.cpp that replaces OMPConstants.cpp). I don't get this comment.

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).

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.

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.

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.

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.

@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?

@jdoerfert Any comments?

Not really, assuming there is nothing specifically new since my last comment here.

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.

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.

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.

Patch D92955 and D93576 are going in this sense.

clementval resigned from this revision.Jan 7 2021, 6:45 AM

Patch D92955 and D93576 were going in this sense and landed. Patch D93560 is moving all to .inc file.