This is an archive of the discontinued LLVM Phabricator instance.

[openmp] Move Directive and Clause helper function to tablegen
ClosedPublic

Authored by clementval on Jun 23 2020, 1:06 PM.

Details

Summary

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

Diff Detail

Event Timeline

clementval created this revision.Jun 23 2020, 1:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 23 2020, 1:06 PM

Fix tiny formatting problem in DirectiveBase.td

Add alternative name and enforce implcit clause

Address some clang-tidy warnings

Fxi comment in DirectiveBase.td

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.

clementval added a comment.EditedJun 24 2020, 1:02 PM

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

Why do we need sections if we generate multiple files?

clementval added a comment.EditedJun 24 2020, 1:26 PM

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.

Why do we need sections if we generate multiple 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?

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.

Why do we need sections if we generate multiple 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.

clementval marked 6 inline comments as done.

Address @jdenny comments

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.

Why do we need sections if we generate multiple 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?

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.

jdenny accepted this revision.Jun 26 2020, 2:24 PM

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.

This revision is now accepted and ready to land.Jun 26 2020, 2:24 PM
clementval added a comment.EditedJun 26 2020, 5:21 PM

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?

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?

clementval edited the summary of this revision. (Show Details)Jun 29 2020, 2:50 PM
clementval marked 2 inline comments as done.
clementval added inline comments.
llvm/test/TableGen/directive2.td
63

I forced to have at least one default now so this reflect here as well.

jdenny added inline comments.Jun 29 2020, 3:22 PM
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?

clementval marked 3 inline comments as done.Jun 29 2020, 3:51 PM
clementval added inline comments.
llvm/test/TableGen/directive2.td
63

The test was not correct. Default should be present as a default is mandatory by the emitter.

jdenny accepted this revision.Jun 29 2020, 4:21 PM
jdenny marked an inline comment as done.

Still LGTM.

llvm/test/TableGen/directive2.td
63

Thanks for clarifying.

clementval marked an inline comment as done.Jun 29 2020, 5:28 PM

Still LGTM.

Thanks for the review. Will push this tomorrow if there is no other comment.

This revision was automatically updated to reflect the committed changes.