This is an archive of the discontinued LLVM Phabricator instance.

[flang][openacc] Basic name resolution infrastructure for OpenACC construct
ClosedPublic

Authored by clementval on Jul 16 2020, 7:22 PM.

Details

Summary

This patch put in place the basic infratrsucture for the name resolutions
in OpenACC constructs. It tries to be as similar as the OpenMP name resolution and
now share a base class DirectiveAttributeVisitor to share most of the base
infrastructure. Follow-up patches will come with more tests and name resolution
in data constructs and data-mapping clauses.

Diff Detail

Event Timeline

clementval created this revision.Jul 16 2020, 7:22 PM
Herald added a project: Restricted Project. · View Herald Transcript
clementval added a project: Restricted Project.Jul 16 2020, 7:24 PM
klausler requested changes to this revision.Jul 17 2020, 10:32 AM
klausler added inline comments.
flang/lib/Semantics/resolve-names.cpp
1085

resolve-names.cpp is already a large source file. Does the directive name resolution code have to be in there in order to use things that are local to that file? If not, maybe all the directive name resolution code could reside elsewhere.

This revision now requires changes to proceed.Jul 17 2020, 10:32 AM
clementval marked an inline comment as done.Jul 17 2020, 11:27 AM
clementval added inline comments.
flang/lib/Semantics/resolve-names.cpp
1085

I think we can move that into a separate file. I'll update the patch. Thanks for the suggestion.

clementval marked an inline comment as done.Jul 17 2020, 12:34 PM
clementval added inline comments.
flang/lib/Semantics/resolve-names.cpp
1085

@klausler I would have to move some class declaration from resolve-name.cpp to resolve-name.h. If this is fine I will split the files.

clementval marked an inline comment as done.Jul 17 2020, 12:49 PM
clementval added inline comments.
flang/lib/Semantics/resolve-names.cpp
1085

In fact most of the class declarations would have to be moved to the resolve-name.h file in order to be able to split the file and have its own for directive resolution.

clementval marked an inline comment as done.Jul 20 2020, 12:33 PM
clementval added inline comments.
flang/lib/Semantics/resolve-names.cpp
1085

After some work on this, this would need to move all the declarations in to a header file (resolve-name.h) because the Acc/OmpVisitor and Acc/OmpAttributeVisitor use classes declared inside resolve-names.cpp and those classes derived from other internal classes as well.

It would be much easier to keep those declarations together. One solution to reduce the size of the file might be to extract the declarations in the .h file and keep only the implementation in the .cpp file but still together. Introducing new files for the directive part makes it harder since they are interdependent.

What do you think is the best to move forward @klausler?

ichoyjx requested changes to this revision.Jul 20 2020, 4:37 PM

Nice work on unifying two programming models' base attribute visitor. I am surprised that they could share most of the utils.

As you could see, the OpenMP part was a WIP work and I only added the PreDetermined attribute. In the future, ExpDetermined (explicitly) and ImpDetermined (implicitly) attributes are also needed. Besides, we have "Data Mapping Attribute" for OpenMP, which will increase the complexity too. Do you picture that OpenACC and OpenMP would work together without an issue using this framework?

flang/lib/Semantics/resolve-names.cpp
1293

I believe this is a typo: OpenMP.

Nice work on unifying two programming models' base attribute visitor. I am surprised that they could share most of the utils.

As you could see, the OpenMP part was a WIP work and I only added the PreDetermined attribute. In the future, ExpDetermined (explicitly) and ImpDetermined (implicitly) attributes are also needed. Besides, we have "Data Mapping Attribute" for OpenMP, which will increase the complexity too. Do you picture that OpenACC and OpenMP would work together without an issue using this framework?

I guess the common base could be shared at least until now and I expect that it should be do-able with the additional attributes. Of course, I'm not against having two separate attribute visitor if we find it is needed when we add attributes in OpenMP and OpenACC. Was just trying to reduce the amount of code that was obviously duplicated in this case. Hopefully we can keep sharing this infra.

Fix type for OpenACCDeclarativeConstruct

clementval marked 2 inline comments as done.Jul 21 2020, 5:58 AM
clementval added inline comments.
flang/lib/Semantics/resolve-names.cpp
1293

Good catch! Just updated the diff.

klausler accepted this revision.Jul 21 2020, 9:04 AM

Please get approval from @tskeith before merging these changes. Thanks for your valuable contributions!

flang/lib/Semantics/resolve-names.cpp
1085

Which classes?

Can they go into resolve-names-utils.{h,cpp} instead?

1085

That may be the case for AccVisitor, but can AccAttributeVisitor be extracted into its own header and C++ source file?

1085

Please don't embark on a wholesale restructuring of resolve-names.cpp without consulting with @tskeith. If there isn't an obvious way to extract the name resolution for directives, just leave it in there.

ichoyjx accepted this revision.Jul 21 2020, 10:59 AM
This revision is now accepted and ready to land.Jul 21 2020, 10:59 AM
clementval marked 7 inline comments as done.Jul 22 2020, 6:55 AM

@klausler Thanks for the feedback. Will wait on @tskeith inputs before going forward.

flang/lib/Semantics/resolve-names.cpp
1085

The problem is that AccAttributeVisitor, OmpAttributeVisitor and DirectiveAttributeVisitor are using ResolveNamesVisitor that is not declared in a .h file but in resolve-names.cpp. This class needs then lots of other classes declared in resolve-names.cpp. So there is no easy way to extract them without a refactoring.

1085

Sure will wait on his inputs.

1085

Basically almost all the classes declared in resolve-names.cpp because one inherits from another or uses other classes and we end up moving the whole things.

clementval marked 3 inline comments as done.Jul 23 2020, 6:33 AM

@tskeith Any input on this?

tskeith added inline comments.Jul 23 2020, 5:02 PM
flang/lib/Semantics/resolve-names.cpp
1085

I think it's a good idea for these to be in a separate file, but it will require some restructuring. The main problem is ResolveDesignator. It is used both to resolve a Designator and to get the Name from an already-resolve designator. It looks like you only need the latter function, and that could be moved to resolve-names-utils.{h,cpp}.

I suggest you land this change without worrying about that restructuring and then I'll take a look at it in a separate change (unless you want to).

1191

This function could be implement as:
return parser::Unwrap<parser::DoConstruct>(x);

6501

Is it worthwhile skipping this unless -fopenacc is present? (Same with OpenMP?)

6855

This return is not reachable.

A better way to write this function might be:

if (!name) {
  return nullptr;
} else if (auto *prev{GetContext().scope.parent().FindCommonBlock(name->source)}) {
  name->symbol  = prev;
  return prev;
} else {
  return nullptr;
}
7433

Do you need to walk the tree twice for the same reason as OpenMP below? If so, can it be a single function with the visitor as a template parameter?

clementval marked 8 inline comments as done.

Address review comments

Thanks for the comment @tskeith. I update the patch and added some comments.

flang/lib/Semantics/resolve-names.cpp
1085

I agree that it should be in a separate file. As you said, it is probably better to land this and have a follow-up patch that does the separation in order to keep the patch "small" and have a better view at what is being done.

Let me know if you want me to have a look at it.

6501

Would make sense I guess. Is there an easy way to query which options are enabled from here?

7433

I see no need to walk the tree twice (at least for the moment with the current status). Just a stupid copy-paste. I updated the code.

tskeith accepted this revision.Jul 24 2020, 9:12 AM
tskeith added inline comments.
flang/lib/Semantics/resolve-names.cpp
6501

Use SemanticsContext::IsEnabled and pass in the LanguageFeature for OpenACC or OpenMP.

clementval marked an inline comment as done.Jul 24 2020, 9:48 AM
clementval added inline comments.
flang/lib/Semantics/resolve-names.cpp
6501

Thanks. I'll update the patch before landing it.

Only resolve OpenACC or OpenMP when they are enabled

tskeith added inline comments.Jul 24 2020, 12:43 PM
flang/lib/Semantics/resolve-names.cpp
6501–6506

You don't need Fortran::. Also, please include braces around the body of the if statements.

6793

This is a good suggestion from clang-tidy. Use const auto rather than just auto when you can.

clementval marked 5 inline comments as done.

Address comments

clementval added inline comments.Jul 26 2020, 5:00 PM
flang/lib/Semantics/resolve-names.cpp
6793

Yeah sure. I normally use it when it makes sense. Good catch from clang-tidy!

This revision was automatically updated to reflect the committed changes.