Follow up to D81736. Move getOpenMPDirectiveKind, getOpenMPClauseKind, getOpenMPDirectiveName and
getOpenMPClauseName to the new tablegen code generation. The code is generated in a new file named OMP.cpp.inc
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
So the idea is we generate a single .inc file with multiple ifdef regions to choose from? Is that what is usually done? I would have thought multiple files are nicer but no strong feeling.
I have no strong opinion on this as well. MLIR is generating two files for their dialects (1 `.h.inc and `.cpp.inc) but use the sections as well. We will probably need the sections as well even if we do two or more files.
So far if we have a .h.inc and a .cpp.inc there is no need for sections for the common parts related to enumerations but I can imagine that some part in clang or Flang which currently use OMPKinds.def need replacement code that are quite specific and might reside in a section. Does it make sense?
That would be for tweaking parts of the content not for selecting entirely different content, right?
It seems unintuitive to me to force two completely different files into one file in this manner, but I have no strong opinion either. If that's the norm, then fine by me.
llvm/include/llvm/Frontend/Directive/DirectiveBase.td | ||
---|---|---|
49 | Could this comment clarify briefly how the alternative name might be used? Likewise for the one in Directive. Also, minor nit: the comments in this file are not consistent about punctuation. My read of the style standard is that punctuation is preferred. | |
55–56 | The effect of isImplicit and isDefault on get*ClauseKind is subtle. Can this be documented here? | |
llvm/test/TableGen/directive1.td | ||
28 | Is this CHECK instead of CHECK-NEXT because there are other lines before that shouldn't be checked? If, instead, this just handles empty lines, CHECK-EMPTY can do that but won't let additional non-empty lines slip in later. Likewise for other cases below. | |
33 | directive -> clause | |
44 | Please consider using indentation within FileCheck directives like this one so that the embedded C++ here is more readable. Also maybe consider using FileCheck -strict-whitespace -match-full-lines to be sure unintentional text or formatting doesn't slip in later. I'll admit, most tests don't do this so that they're less brittle, but I feel like that's not likely an issue here. Of course, some of that might need to go in a later review so this review remains easy to read. | |
llvm/utils/TableGen/DirectiveEmitter.cpp | ||
332 | Please use the style /*ParamName=*/constant for arguments like false. |
That's used for selecting different part. It is done like this both in pure TableGen and miler-tablegen uses.
It seems unintuitive to me to force two completely different files into one file in this manner, but I have no strong opinion either. If that's the norm, then fine by me.
As I said, I have no strong opinion but we could at least keep a .h.inc file clean if we choose a two files approache.
It would still be nice to see the normal C++ indentation in the generated file and in the test suite. As I said, that could go in a separate patch.
Otherwise, this LGTM. Please give others a few more days to review, especially given the discussion about splitting the .inc file.
Sure, I don't mind adding the indentation here or in a follow up. About the file splitting I would be in favor to split in at least two files but with no string opinion as said before. What about you @jdenny, @jdoerfert?
So far, it seems that the three of us slightly prefer splitting, and it seems there's some precedent for this in mlir. If @thakis or others do not object today, then maybe just go with what you think is right. It can always be changed later.
+1 for splitting it into logical consistent files.
One source that generates what you need in different places.
Split file and add some indentation to the generated code. @jdenny @jdoerfert It should be ready to land now.
Be sure to update the summary where it talks about OMP.inc.
Thanks for adjusting the indentation.
llvm/test/TableGen/directive2.td | ||
---|---|---|
63 | Why did .Default just show up here in this update? |
llvm/test/TableGen/directive2.td | ||
---|---|---|
63 | I forced to have at least one default now so this reflect here as well. |
llvm/test/TableGen/directive2.td | ||
---|---|---|
63 | Before this update (Diff 7) to this review, TDLD_dira and TDLC_clauseb were already set as defaults, but .Default didn't show up in these switches. Was the test case broken, or did something subtle change in the emitter? |
llvm/test/TableGen/directive2.td | ||
---|---|---|
63 | The test was not correct. Default should be present as a default is mandatory by the emitter. |
Could this comment clarify briefly how the alternative name might be used? Likewise for the one in Directive.
Also, minor nit: the comments in this file are not consistent about punctuation. My read of the style standard is that punctuation is preferred.