[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 11 inline comments as done.
lildmh added a comment.

Hi Alexey,

Thanks a lot for the review! For 3 places I have doubt. Please see the comments 
inline. I tried to fix the rest of your comments.




Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> No, bad idea. Use tail allocation for the clauses. Check the implementation 
> of `OMPRequiresDecl`
I think it is possible to use TrailingObjects for clause storage when the 
number of clauses are known before creating the directive (e.g., for 
OMPRequiresDecl and OMPExecutableDirective). 

The reason that I had to create OMPDeclareMapperDecl before parsing map 
clauses, is the mapper variable (AA in the example below) needs to be declared 
within OMPDeclareMapperDecl, because the following map clauses will use it.

```
#pragma omp declare mapper(struct S AA) map(AA.field1)
```

A possible way to get around this is to count the number of map clauses before 
hand. But this solution is not trivial since the normal method for parsing map 
clauses cannot be used (e.g., it does not know AA when parsing map(AA.field1)). 
A customized and complex (because it needs to handle all possible situations) 
parsing method needs to be created, just for counting clause number. I think 
it's not worthy to do this compared with allocating map clause space later.

I checked the code for OMPDeclareReductionDecl that you wrote. It also has to 
be created before parsing the combiner and initializer. It does not have a 
variable number of clauses though.

Any suggestions?



Comment at: lib/Sema/SemaTemplateInstantiateDecl.cpp:2868
+TemplateDeclInstantiator::VisitOMPDeclareMapperDecl(OMPDeclareMapperDecl *D) {
+  assert(!D->getType()->isDependentType() &&
+ !D->getType()->isInstantiationDependentType() &&

ABataev wrote:
> Why?
Thanks! I was wrong about this. Has fixed it in the new patch. Please check



Comment at: lib/Serialization/ASTReader.cpp:12304
   for (unsigned i = 0; i != NumVars; ++i)
-Vars.push_back(Record.readSubExpr());
+Vars.push_back(Record.readExpr());
   C->setVarRefs(Vars);

ABataev wrote:
> Restore original
I found using readSubExpr does not work with declare mapper. The reasons are as 
follows:

readSubExpr will call ASTReader::ReadSubExpr, which will call ReadSubStmt. 
ReadSubStmt only works with Stmt.

Before, this is correct because map clauses only come with 
OMPExecutableDirective, which is a Stmt.

Now, map clauses can come with OMPDeclareMapperDecl, which is a Decl. 
ReadSubStmt does not work with Decl. Instead, readExpr will call 
ASTReader::ReadExpr. ASTReader::ReadExpr calls ReadSubStmt if it is a Stmt, and 
it calls ReadStmtFromStream if it is a Decl. The map clause information is 
indeed in the stream for OMPDeclareMapperDecl. So I use readExpr instead.

This modification should not affect the behavior of map clause serialization 
for existing directives that are Stmts, since they will both call ReadSubStmt 
in the end. The regression test confirms that.

Any suggestions?



Comment at: lib/Serialization/ASTReader.cpp:12328
   for (unsigned i = 0; i < TotalComponents; ++i) {
-Expr *AssociatedExpr = Record.readSubExpr();
+Expr *AssociatedExpr = Record.readExpr();
 auto *AssociatedDecl = Record.readDeclAs();

ABataev wrote:
> Restore original
The same as above.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 181289.
lildmh marked an inline comment as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6230,6 +6230,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
+
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(id1: vec v)

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > No, bad idea. Use tail allocation for the clauses. Check the 
> > > implementation of `OMPRequiresDecl`
> > I think it is possible to use TrailingObjects for clause storage when the 
> > number of clauses are known before creating the directive (e.g., for 
> > OMPRequiresDecl and OMPExecutableDirective). 
> > 
> > The reason that I had to create OMPDeclareMapperDecl before parsing map 
> > clauses, is the mapper variable (AA in the example below) needs to be 
> > declared within OMPDeclareMapperDecl, because the following map clauses 
> > will use it.
> > 
> > ```
> > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > ```
> > 
> > A possible way to get around this is to count the number of map clauses 
> > before hand. But this solution is not trivial since the normal method for 
> > parsing map clauses cannot be used (e.g., it does not know AA when parsing 
> > map(AA.field1)). A customized and complex (because it needs to handle all 
> > possible situations) parsing method needs to be created, just for counting 
> > clause number. I think it's not worthy to do this compared with allocating 
> > map clause space later.
> > 
> > I checked the code for OMPDeclareReductionDecl that you wrote. It also has 
> > to be created before parsing the combiner and initializer. It does not have 
> > a variable number of clauses though.
> > 
> > Any suggestions?
> Instead, you can introduce special DeclContext-based declaration and keep the 
> reference to this declaration inside of the `OMPDeclareMapperDecl`.
Hi Alexey,

Thanks a lot for your quick response! I don't think I understand your idea. Can 
you establish more on that?

In my current implementation, OMPDeclareMapperDecl is used as the DeclConext of 
the variable AA in the above example, and it already includes the reference to 
AA's declaration.

My problem is, I need to create OMPDeclareMapperDecl before parsing map 
clauses. But before parsing map clauses, I don't know the number of clauses. 
Using TrailingObject requires to know how many clauses there are when creating 
OMPDeclareMapperDecl. So I couldn't use TrailingObject.

My current solution is to create OMPDeclareMapperDecl before parsing map 
clauses, and to create the clause storage after parsing finishes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > No, bad idea. Use tail allocation for the clauses. Check the 
> > > > > implementation of `OMPRequiresDecl`
> > > > I think it is possible to use TrailingObjects for clause storage when 
> > > > the number of clauses are known before creating the directive (e.g., 
> > > > for OMPRequiresDecl and OMPExecutableDirective). 
> > > > 
> > > > The reason that I had to create OMPDeclareMapperDecl before parsing map 
> > > > clauses, is the mapper variable (AA in the example below) needs to be 
> > > > declared within OMPDeclareMapperDecl, because the following map clauses 
> > > > will use it.
> > > > 
> > > > ```
> > > > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > > > ```
> > > > 
> > > > A possible way to get around this is to count the number of map clauses 
> > > > before hand. But this solution is not trivial since the normal method 
> > > > for parsing map clauses cannot be used (e.g., it does not know AA when 
> > > > parsing map(AA.field1)). A customized and complex (because it needs to 
> > > > handle all possible situations) parsing method needs to be created, 
> > > > just for counting clause number. I think it's not worthy to do this 
> > > > compared with allocating map clause space later.
> > > > 
> > > > I checked the code for OMPDeclareReductionDecl that you wrote. It also 
> > > > has to be created before parsing the combiner and initializer. It does 
> > > > not have a variable number of clauses though.
> > > > 
> > > > Any suggestions?
> > > Instead, you can introduce special DeclContext-based declaration and keep 
> > > the reference to this declaration inside of the `OMPDeclareMapperDecl`.
> > Hi Alexey,
> > 
> > Thanks a lot for your quick response! I don't think I understand your idea. 
> > Can you establish more on that?
> > 
> > In my current implementation, OMPDeclareMapperDecl is used as the 
> > DeclConext of the variable AA in the above example, and it already includes 
> > the reference to AA's declaration.
> > 
> > My problem is, I need to create OMPDeclareMapperDecl before parsing map 
> > clauses. But before parsing map clauses, I don't know the number of 
> > clauses. Using TrailingObject requires to know how many clauses there are 
> > when creating OMPDeclareMapperDecl. So I couldn't use TrailingObject.
> > 
> > My current solution is to create OMPDeclareMapperDecl before parsing map 
> > clauses, and to create the clause storage after parsing finishes.
> What I meant, that you don't need to use `OMPDeclareMapperDecl` for this, 
> instead you can add another (very simple) special declaration based on 
> `DeclContext` to use it as the parent declaration for the variable. In the 
> `OMPDeclareMapperDecl` you can keep the reference to this special declaration.
Thanks for your response! Please let me know if my understanding below is 
correct:

`OMPDeclareMapperDecl` no longer inherits from `DeclContext`. Instead, we 
create something like `OMPDeclareMapperDeclContext` which inherits from 
`DeclContext`, and `OMPDeclareMapperDecl` keeps a pointer that points to this 
`OMPDeclareMapperDeclContext`.  AA and map clauses are parsed within 
`OMPDeclareMapperDeclContext`.

This sounds a bit more complex, but if you believe it's better, I can change 
the code. Please share your thoughts.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > No, bad idea. Use tail allocation for the clauses. Check the 
> > > > > > > implementation of `OMPRequiresDecl`
> > > > > > I think it is possible to use TrailingObjects for clause storage 
> > > > > > when the number of clauses are known before creating the directive 
> > > > > > (e.g., for OMPRequiresDecl and OMPExecutableDirective). 
> > > > > > 
> > > > > > The reason that I had to create OMPDeclareMapperDecl before parsing 
> > > > > > map clauses, is the mapper variable (AA in the example below) needs 
> > > > > > to be declared within OMPDeclareMapperDecl, because the following 
> > > > > > map clauses will use it.
> > > > > > 
> > > > > > ```
> > > > > > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > > > > > ```
> > > > > > 
> > > > > > A possible way to get around this is to count the number of map 
> > > > > > clauses before hand. But this solution is not trivial since the 
> > > > > > normal method for parsing map clauses cannot be used (e.g., it does 
> > > > > > not know AA when parsing map(AA.field1)). A customized and complex 
> > > > > > (because it needs to handle all possible situations) parsing method 
> > > > > > needs to be created, just for counting clause number. I think it's 
> > > > > > not worthy to do this compared with allocating map clause space 
> > > > > > later.
> > > > > > 
> > > > > > I checked the code for OMPDeclareReductionDecl that you wrote. It 
> > > > > > also has to be created before parsing the combiner and initializer. 
> > > > > > It does not have a variable number of clauses though.
> > > > > > 
> > > > > > Any suggestions?
> > > > > Instead, you can introduce special DeclContext-based declaration and 
> > > > > keep the reference to this declaration inside of the 
> > > > > `OMPDeclareMapperDecl`.
> > > > Hi Alexey,
> > > > 
> > > > Thanks a lot for your quick response! I don't think I understand your 
> > > > idea. Can you establish more on that?
> > > > 
> > > > In my current implementation, OMPDeclareMapperDecl is used as the 
> > > > DeclConext of the variable AA in the above example, and it already 
> > > > includes the reference to AA's declaration.
> > > > 
> > > > My problem is, I need to create OMPDeclareMapperDecl before parsing map 
> > > > clauses. But before parsing map clauses, I don't know the number of 
> > > > clauses. Using TrailingObject requires to know how many clauses there 
> > > > are when creating OMPDeclareMapperDecl. So I couldn't use 
> > > > TrailingObject.
> > > > 
> > > > My current solution is to create OMPDeclareMapperDecl before parsing 
> > > > map clauses, and to create the clause storage after parsing finishes.
> > > What I meant, that you don't need to use `OMPDeclareMapperDecl` for this, 
> > > instead you can add another (very simple) special declaration based on 
> > > `DeclContext` to use it as the parent declaration for the variable. In 
> > > the `OMPDeclareMapperDecl` you can keep the reference to this special 
> > > declaration.
> > Thanks for your response! Please let me know if my understanding below is 
> > correct:
> > 
> > `OMPDeclareMapperDecl` no longer inherits from `DeclContext`. Instead, we 
> > create something like `OMPDeclareMapperDeclContext` which inherits from 
> > `DeclContext`, and `OMPDeclareMapperDecl` keeps a pointer that points to 
> > this `OMPDeclareMapperDeclContext`.  AA and map clauses are parsed within 
> > `OMPDeclareMapperDeclContext`.
> > 
> > This sounds a bit more complex, but if you believe it's better, I can 
> > change the code. Please share your thoughts.
> Yes, something like this.
Hi Alexey,

Sorry for the late response. I was working on something else last week.

When I tried to modify the code based on your suggestions, I found out that 
`DeclContext` is only meant to be used for a `Decl` (please see the comments 
before `class DeclContext {...}` in include/clang/AST/DeclBase.h).

It means, if I create a `OMPDeclareMapperDeclContext ` which is a `DeclContext 
` but not a `Decl`, the code cannot work correctly. Therefore 
`OMPDeclareMapperDeclContext` must be a `Decl` itself. If I do it this way, a 
lot of useless information (all inherited from `Decl`) will exist within 
`OMPDeclareMapperDeclContext`, which is very inefficient.

An alternative way is to have something called `OMPDeclareMapperClauses` that 
inherits from `TrailingObject` to store clause information, and 
`OMPDeclareMapperDecl` keeps a pointer that points to 
`OMPDeclareMapperClauses`. But I don't think this is better than just having a 
`OMPClause **Clauses`, which is my current implementation.

What do you think?


CHANGES 

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > No, bad idea. Use tail allocation for the clauses. Check the 
> > > > > > > > > implementation of `OMPRequiresDecl`
> > > > > > > > I think it is possible to use TrailingObjects for clause 
> > > > > > > > storage when the number of clauses are known before creating 
> > > > > > > > the directive (e.g., for OMPRequiresDecl and 
> > > > > > > > OMPExecutableDirective). 
> > > > > > > > 
> > > > > > > > The reason that I had to create OMPDeclareMapperDecl before 
> > > > > > > > parsing map clauses, is the mapper variable (AA in the example 
> > > > > > > > below) needs to be declared within OMPDeclareMapperDecl, 
> > > > > > > > because the following map clauses will use it.
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > A possible way to get around this is to count the number of map 
> > > > > > > > clauses before hand. But this solution is not trivial since the 
> > > > > > > > normal method for parsing map clauses cannot be used (e.g., it 
> > > > > > > > does not know AA when parsing map(AA.field1)). A customized and 
> > > > > > > > complex (because it needs to handle all possible situations) 
> > > > > > > > parsing method needs to be created, just for counting clause 
> > > > > > > > number. I think it's not worthy to do this compared with 
> > > > > > > > allocating map clause space later.
> > > > > > > > 
> > > > > > > > I checked the code for OMPDeclareReductionDecl that you wrote. 
> > > > > > > > It also has to be created before parsing the combiner and 
> > > > > > > > initializer. It does not have a variable number of clauses 
> > > > > > > > though.
> > > > > > > > 
> > > > > > > > Any suggestions?
> > > > > > > Instead, you can introduce special DeclContext-based declaration 
> > > > > > > and keep the reference to this declaration inside of the 
> > > > > > > `OMPDeclareMapperDecl`.
> > > > > > Hi Alexey,
> > > > > > 
> > > > > > Thanks a lot for your quick response! I don't think I understand 
> > > > > > your idea. Can you establish more on that?
> > > > > > 
> > > > > > In my current implementation, OMPDeclareMapperDecl is used as the 
> > > > > > DeclConext of the variable AA in the above example, and it already 
> > > > > > includes the reference to AA's declaration.
> > > > > > 
> > > > > > My problem is, I need to create OMPDeclareMapperDecl before parsing 
> > > > > > map clauses. But before parsing map clauses, I don't know the 
> > > > > > number of clauses. Using TrailingObject requires to know how many 
> > > > > > clauses there are when creating OMPDeclareMapperDecl. So I couldn't 
> > > > > > use TrailingObject.
> > > > > > 
> > > > > > My current solution is to create OMPDeclareMapperDecl before 
> > > > > > parsing map clauses, and to create the clause storage after parsing 
> > > > > > finishes.
> > > > > What I meant, that you don't need to use `OMPDeclareMapperDecl` for 
> > > > > this, instead you can add another (very simple) special declaration 
> > > > > based on `DeclContext` to use it as the parent declaration for the 
> > > > > variable. In the `OMPDeclareMapperDecl` you can keep the reference to 
> > > > > this special declaration.
> > > > Thanks for your response! Please let me know if my understanding below 
> > > > is correct:
> > > > 
> > > > `OMPDeclareMapperDecl` no longer inherits from `DeclContext`. Instead, 
> > > > we create something like `OMPDeclareMapperDeclContext` which inherits 
> > > > from `DeclContext`, and `OMPDeclareMapperDecl` keeps a pointer that 
> > > > points to this `OMPDeclareMapperDeclContext`.  AA and map clauses are 
> > > > parsed within `OMPDeclareMapperDeclContext`.
> > > > 
> > > > This sounds a bit more complex, but if you believe it's better, I can 
> > > > change the code. Please share your thoughts.
> > > Yes, something like this.
> > Hi Alexey,
> > 
> > Sorry for the late response. I was working on something else last week.
> > 
> > When I tried to modify the code based on your suggestions, I found out that 
> > `DeclContext` is only meant to be used for a `Decl` (please see the 
> > comments before `class DeclContext {...}` in include/clang/AST/DeclBase.h).
> > 
> > It means, if I create a `OMPDeclareMapperDeclContext ` which is a 
> > `DeclContext ` but not a `Decl`, the code cannot work correctly. Therefore 
> > `OMPDeclareMapperDeclContext` must be a `Decl` itself. If I do it this way, 
> > a lot of useless information (all inherited from `Decl`) will exist within 
> > `OMPD

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/AST/DeclOpenMP.cpp:164
+  if (NumClauses) {
+Clauses = (OMPClause **)C.Allocate(sizeof(OMPClause *) * NumClauses);
+setClauses(CL);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > No, bad idea. Use tail allocation for the clauses. Check 
> > > > > > > > > > > the implementation of `OMPRequiresDecl`
> > > > > > > > > > I think it is possible to use TrailingObjects for clause 
> > > > > > > > > > storage when the number of clauses are known before 
> > > > > > > > > > creating the directive (e.g., for OMPRequiresDecl and 
> > > > > > > > > > OMPExecutableDirective). 
> > > > > > > > > > 
> > > > > > > > > > The reason that I had to create OMPDeclareMapperDecl before 
> > > > > > > > > > parsing map clauses, is the mapper variable (AA in the 
> > > > > > > > > > example below) needs to be declared within 
> > > > > > > > > > OMPDeclareMapperDecl, because the following map clauses 
> > > > > > > > > > will use it.
> > > > > > > > > > 
> > > > > > > > > > ```
> > > > > > > > > > #pragma omp declare mapper(struct S AA) map(AA.field1)
> > > > > > > > > > ```
> > > > > > > > > > 
> > > > > > > > > > A possible way to get around this is to count the number of 
> > > > > > > > > > map clauses before hand. But this solution is not trivial 
> > > > > > > > > > since the normal method for parsing map clauses cannot be 
> > > > > > > > > > used (e.g., it does not know AA when parsing 
> > > > > > > > > > map(AA.field1)). A customized and complex (because it needs 
> > > > > > > > > > to handle all possible situations) parsing method needs to 
> > > > > > > > > > be created, just for counting clause number. I think it's 
> > > > > > > > > > not worthy to do this compared with allocating map clause 
> > > > > > > > > > space later.
> > > > > > > > > > 
> > > > > > > > > > I checked the code for OMPDeclareReductionDecl that you 
> > > > > > > > > > wrote. It also has to be created before parsing the 
> > > > > > > > > > combiner and initializer. It does not have a variable 
> > > > > > > > > > number of clauses though.
> > > > > > > > > > 
> > > > > > > > > > Any suggestions?
> > > > > > > > > Instead, you can introduce special DeclContext-based 
> > > > > > > > > declaration and keep the reference to this declaration inside 
> > > > > > > > > of the `OMPDeclareMapperDecl`.
> > > > > > > > Hi Alexey,
> > > > > > > > 
> > > > > > > > Thanks a lot for your quick response! I don't think I 
> > > > > > > > understand your idea. Can you establish more on that?
> > > > > > > > 
> > > > > > > > In my current implementation, OMPDeclareMapperDecl is used as 
> > > > > > > > the DeclConext of the variable AA in the above example, and it 
> > > > > > > > already includes the reference to AA's declaration.
> > > > > > > > 
> > > > > > > > My problem is, I need to create OMPDeclareMapperDecl before 
> > > > > > > > parsing map clauses. But before parsing map clauses, I don't 
> > > > > > > > know the number of clauses. Using TrailingObject requires to 
> > > > > > > > know how many clauses there are when creating 
> > > > > > > > OMPDeclareMapperDecl. So I couldn't use TrailingObject.
> > > > > > > > 
> > > > > > > > My current solution is to create OMPDeclareMapperDecl before 
> > > > > > > > parsing map clauses, and to create the clause storage after 
> > > > > > > > parsing finishes.
> > > > > > > What I meant, that you don't need to use `OMPDeclareMapperDecl` 
> > > > > > > for this, instead you can add another (very simple) special 
> > > > > > > declaration based on `DeclContext` to use it as the parent 
> > > > > > > declaration for the variable. In the `OMPDeclareMapperDecl` you 
> > > > > > > can keep the reference to this special declaration.
> > > > > > Thanks for your response! Please let me know if my understanding 
> > > > > > below is correct:
> > > > > > 
> > > > > > `OMPDeclareMapperDecl` no longer inherits from `DeclContext`. 
> > > > > > Instead, we create something like `OMPDeclareMapperDeclContext` 
> > > > > > which inherits from `DeclContext`, and `OMPDeclareMapperDecl` keeps 
> > > > > > a pointer that points to this `OMPDeclareMapperDeclContext`.  AA 
> > > > > > and map clauses are parsed within `OMPDeclareMapperDeclContext`.
> > > > > > 
> > > > > > This sounds a bit more complex, but if you believe it's better, I 
> > > > > > can change the code. Please share your thoughts.
> > > > > Yes, something like this.
> > > > Hi Alexey,
> > > > 
> > > > Sorry for the late response. I was working on something else last week.
> > > > 
> > > > When I tried to modify the code based on your suggestions, I found out 
> > > > that `DeclContext` is only meant to be used for a `Decl` (please see 
>

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 183570.
lildmh added a comment.

Change the type of mapper clause storage from OMPClause ** to 
MutableArrayRef, and rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6228,6 +6228,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
+
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 18 inline comments as done.
lildmh added a comment.

Hi Alexey,

Thanks a lot for the review! Tried to address all of your comments in the new 
diff.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 183615.
lildmh added a comment.

Address review comments and rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6228,6 +6228,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
+
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declar

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
lildmh added reviewers: ABataev, hfinkel, Meinersbur, kkwli0.
lildmh added a project: OpenMP.
Herald added subscribers: cfe-commits, jdoerfert, guansong.
Herald added a project: clang.

This patch implements the code generation for OpenMP 5.0 declare mapper 
(user-defined mapper) constructs. For each declare mapper, a synchronous 
mapping function as well as an asynchronous one are generated, which will be 
called by the runtime to achieve user defined mapping.


Repository:
  rC Clang

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,770 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 196880.
lildmh added a comment.

Combine 2 pointers into one.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,770 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 3 inline comments as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:2390
   }
+  case OMPRTL__tgt_target_data_mapper: {
+// Build void __tgt_target_data_mapper(int64_t device_id, int32_t arg_num,

ABataev wrote:
> You need to implement these mapper functions first.
The runtime part is on hold for now.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:351
+  /// is the asynchronous version.
+  llvm::DenseMap>

ABataev wrote:
> You should be very careful with this map. If the mapper is declared in the 
> function context, it must be removed from this map as soon as the function 
> processing is completed. All local declarations are removed after this and 
> their address might be used again.
Yes, I plan to have this part in the next patch, which will implement to look 
up the corresponding mapper function for map. to, from clauses


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 7 inline comments as done.
lildmh added a comment.

Hi Alexey,

Again, thanks for your review! Sorry I didn't get back to you in time because I 
was distracted by other things. Please see the comments inline.




Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8021
+  /// the extracted map clauses.
+  void generateAllInfoForMapper(MapBaseValuesArrayTy &BasePointers,
+MapValuesArrayTy &Pointers,

ABataev wrote:
> This code has too many common parts with the existing one. Is it possible to 
> merge it somehow or outline into a function?
I tried to merge it with `generateAllInfo`. The problem is `generateAllInfo` 
also generates information for clauses including `to, from, is_device_ptr, 
use_device_ptr`, which don't exist for `declare mapper`. There is no clear way 
to extract them separately. For example, every 4 or 5 lines, the code is 
intended to address a different clause type.
At last, I think the most clear way is to extract all code related to map 
clauses into this function `generateAllInfoForMapper`. It's ~70 lines of code 
so not too much.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8530
+  // dynamically.
+  QualType MapArrayType = Ctx.getConstantArrayType(
+  Ctx.getIntTypeForBitwidth(/*DestWidth*/ 64, /*Signed*/ true),

ABataev wrote:
> Hmm, how could you calculate the required size of the array for the mapper? 
> Or this is constant?
I'm not sure I understand your question here.
Do you mean the size when an OpenMP array section is mapped? If that's the 
case, it is not constant. Existing code can already handle it.
Or do you mean the size of mapper array (i.e., `MapArrayType`)? This is 
constant and depends on how many map clauses exist in the declare mapper 
directive.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8588
+
+  if (IsMapper) {
+// Combine the map type inherited from user-defined mapper with that

ABataev wrote:
> I think it would be good to move this part to the runtime. We should just 
> pass the mapper function to the runtime functions and the runtime should call 
> those mapper functions and get base pointers, pointers, sizes and maptypes.
This part cannot be moved into the runtime, because the runtime does not know 
the map type associated with the mapper. Another argument can be potentially 
added to the runtime API, but that will be more work and I don't think it's 
necessary



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8795
+  // Generate an asynchronous mapper function.
+  llvm::Function *AsyncFn = emitUDMapperFunc(D, /*NoWait=*/true);
+  // Add the generated mapper functions to UDMMap.

ABataev wrote:
> With the buffering-based implementation we need only function.
Yes, in either case, we only generate functions here. Is there a problem?



Comment at: lib/CodeGen/CGOpenMPRuntime.h:351
+  /// is the asynchronous version.
+  llvm::DenseMap>

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > You should be very careful with this map. If the mapper is declared in 
> > > the function context, it must be removed from this map as soon as the 
> > > function processing is completed. All local declarations are removed 
> > > after this and their address might be used again.
> > Yes, I plan to have this part in the next patch, which will implement to 
> > look up the corresponding mapper function for map. to, from clauses
> Noope, this must be the part of this patch, because it may cause the crash of 
> the compiler during testing.
It will not crash the compiler, because this UDMap is only written in this 
patch, never read.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 198050.
lildmh added a comment.

Fix code format


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,770 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 3 inline comments as done.
lildmh added a comment.

Hi Alexey,

Let's discuss your runtime data mapping scheme next week first. After that we 
will continue the review of this.




Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8530
+  // dynamically.
+  QualType MapArrayType = Ctx.getConstantArrayType(
+  Ctx.getIntTypeForBitwidth(/*DestWidth*/ 64, /*Signed*/ true),

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Hmm, how could you calculate the required size of the array for the 
> > > mapper? Or this is constant?
> > I'm not sure I understand your question here.
> > Do you mean the size when an OpenMP array section is mapped? If that's the 
> > case, it is not constant. Existing code can already handle it.
> > Or do you mean the size of mapper array (i.e., `MapArrayType`)? This is 
> > constant and depends on how many map clauses exist in the declare mapper 
> > directive.
> Yes, it is the question about the size of mapper array. It is the part of our 
> discussion about mappers generation we had before. You said that it is hard 
> to generate the sizes of the arrays since we don't know the number of map 
> clauses at the codegen phase. bu there we have this number.
Sorry there was probably some miscommunication. What I meant is that after 
fully expanded, for example, from `map(mapper(id):a[0:n])`, eventually to 
`map(a.b.c[0:e]) map(a.k) ...`, the number of things in the results is unknown 
at compile time.

Here, we only do one level of expansion of one instance based on the `declare 
mapper` directive, for example, the mapper is `declare mapper(class A a) 
map(a.b[0:a.n]) map(a.c)`
In this case, the size of mapper array is 2, because there are 2 map clauses 
(actually it's more than 2 because the first map clause maps an array). This 
number can be decided at compile time easily.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8795
+  // Generate an asynchronous mapper function.
+  llvm::Function *AsyncFn = emitUDMapperFunc(D, /*NoWait=*/true);
+  // Add the generated mapper functions to UDMMap.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > With the buffering-based implementation we need only function.
> > Yes, in either case, we only generate functions here. Is there a problem?
> Sorry, I meant we'll need only one function.
Yes, in that case, only one is needed.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:351
+  /// is the asynchronous version.
+  llvm::DenseMap>

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > You should be very careful with this map. If the mapper is declared 
> > > > > in the function context, it must be removed from this map as soon as 
> > > > > the function processing is completed. All local declarations are 
> > > > > removed after this and their address might be used again.
> > > > Yes, I plan to have this part in the next patch, which will implement 
> > > > to look up the corresponding mapper function for map. to, from clauses
> > > Noope, this must be the part of this patch, because it may cause the 
> > > crash of the compiler during testing.
> > It will not crash the compiler, because this UDMap is only written in this 
> > patch, never read.
> Still, you should clear it in this patch. Otherwise, you're breaking 
> data-dependency between the patches and this is not good at all.
Sure, if you think that's absolutely necessary, I can add it to this patch.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 184740.
lildmh added a comment.
Herald added a subscriber: openmp-commits.

Rebase.

Hi Alexey,

Thanks a lot for the review! It seems no one else will review it. If you think 
it's ready to go, could you please accept this patch? I also need help to 
commit this patch since I don't have the privilege.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6229,6 +6229,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{ext

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Thanks a lot Alexey!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D56326#1381229 , @Meinersbur wrote:

> @lildmh Thanks for the patch. I can commit this patch for you. The tests run 
> fine on my machine. However, for committing on other's behalf, we were asked 
> to make the contributor aware that the contribution will be published under a 
> new license 
> .
>  Are you OK with the new license?


Thanks a lot Michael! I'm fine with the license.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
lildmh added reviewers: ABataev, hfinkel, Meinersbur.
lildmh added a project: OpenMP.
Herald added subscribers: cfe-commits, guansong.
Herald added a project: clang.

This patch implements the parsing and sema support for OpenMP map clauses with 
potential user-defined mapper attached. User defined mapper is a new feature in 
OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, 
which instructs the compiler to generate extra data mapping. An example is 
shown below:

  struct S { int len; int *d; };
  #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
  struct S ss;
  #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 
'id' to map ss


Repository:
  rC Clang

https://reviews.llvm.org/D58074

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  test/OpenMP/target_teams_map_messages.cpp

Index: test/OpenMP/target_teams_map_messages.cpp
===
--- test/OpenMP/target_teams_map_messages.cpp
+++ test/OpenMP/target_teams_map_messages.cpp
@@ -454,7 +454,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
@@ -529,7 +529,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
Index: test/OpenMP/target_teams_distribute_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
@@ -271,7 +271,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} 

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 186338.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  test/OpenMP/target_teams_map_messages.cpp

Index: test/OpenMP/target_teams_map_messages.cpp
===
--- test/OpenMP/target_teams_map_messages.cpp
+++ test/OpenMP/target_teams_map_messages.cpp
@@ -454,7 +454,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
@@ -529,7 +529,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
Index: test/OpenMP/target_teams_distribute_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
@@ -271,7 +271,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
Index: test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute parallel for simd map(always: x) // expected-error {{missing map 

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 11 inline comments as done.
lildmh added a comment.

Hi Alexey,

Thanks very much for your quick review!

For the codegen, currently I'm thinking to do it within declare target codegen 
functions. So there is not a very clear interface to do mapper codegen (also, 
there is not a clear interface to do map clause codegen now), and that's why I 
didn't have a stub left in this patch. Please see other detailed responses 
inline.




Comment at: include/clang/AST/OpenMPClause.h:4236
+  static OMPMapClause *
+  Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation 
LParenLoc,
+ SourceLocation EndLoc, ArrayRef Vars,

ABataev wrote:
> The function has more than 10 parameters, it is not too good. Would be good 
> to pack some of them into some kind of structure.
I can define a structure `OMPMapClauseModifier` within `OMPMapClause` to 
include all modifier related info. What do you think?



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> Why do we need special processing of the mapper here?
The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s with the 
same name (the same as declare reduction lookup), and thus it goes through all 
scopes from the innermost to the outtermost.

Then it looks up a parent scope S (e.g., the outter {} in the following 
example), all `OMPDeclareMapperDecl`s declared in the children scopes of S will 
appear in the range between `IdResolver.begin(Name)` and `IdResolver.end()`. 
Also, the `declare mapper(id: struct S s)` will appear before `omp declare 
mapper(id: struct SS ss)`. This can cause the lookup function to ignore later 
`omp declare mapper(id: struct SS ss)` declared in the outter scope. As a 
result, we may not find the corrent mapper.

```
{
  #pragma omp declare mapper(id: struct S s) (s.a)
  {
#pragma omp declare mapper(id: struct SS ss) (ss.b)
...
  }
}
```

To fix this problem, the purpose of this part of code is to ignore all 
`OMPDeclareMapperDecl`s in inner scopes, which are already found in previous 
calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.

I also found that the declare reduction lookup has the same problem. I'll push 
out a similar fix for the declare reduction later.



Comment at: lib/Sema/SemaLookup.cpp:1793
   continue;
+else if (NameKind == LookupOMPMapperName) {
+  // Skip out-of-scope declarations.

ABataev wrote:
> Again, what's so special in mapper lookup?
The same as above. This is to fix C lookup, and the above is for C++



Comment at: lib/Serialization/ASTReader.cpp:12312
+  UDMappers.reserve(NumVars);
+  for (unsigned i = 0; i < NumVars; ++i)
+UDMappers.push_back(Record.readExpr());

ABataev wrote:
> `i`->`I`
I fixed it. Lower case `i` is also used in other loops in this function. Would 
you like me to fix them as well?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 186492.
lildmh marked 3 inline comments as done.
lildmh added a comment.

Fix part of Alexey's comments


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  test/OpenMP/target_teams_map_messages.cpp

Index: test/OpenMP/target_teams_map_messages.cpp
===
--- test/OpenMP/target_teams_map_messages.cpp
+++ test/OpenMP/target_teams_map_messages.cpp
@@ -454,7 +454,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
@@ -529,7 +529,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
Index: test/OpenMP/target_teams_distribute_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
@@ -271,7 +271,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
Index: test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pra

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 2 inline comments as done.
lildmh added inline comments.



Comment at: include/clang/AST/OpenMPClause.h:4236
+  static OMPMapClause *
+  Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation 
LParenLoc,
+ SourceLocation EndLoc, ArrayRef Vars,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > The function has more than 10 parameters, it is not too good. Would be 
> > > good to pack some of them into some kind of structure.
> > I can define a structure `OMPMapClauseModifier` within `OMPMapClause` to 
> > include all modifier related info. What do you think?
> Yes, it would be good
Then I'll do that. Thanks



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Why do we need special processing of the mapper here?
> > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s with 
> > the same name (the same as declare reduction lookup), and thus it goes 
> > through all scopes from the innermost to the outtermost.
> > 
> > Then it looks up a parent scope S (e.g., the outter {} in the following 
> > example), all `OMPDeclareMapperDecl`s declared in the children scopes of S 
> > will appear in the range between `IdResolver.begin(Name)` and 
> > `IdResolver.end()`. Also, the `declare mapper(id: struct S s)` will appear 
> > before `omp declare mapper(id: struct SS ss)`. This can cause the lookup 
> > function to ignore later `omp declare mapper(id: struct SS ss)` declared in 
> > the outter scope. As a result, we may not find the corrent mapper.
> > 
> > ```
> > {
> >   #pragma omp declare mapper(id: struct S s) (s.a)
> >   {
> > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > ...
> >   }
> > }
> > ```
> > 
> > To fix this problem, the purpose of this part of code is to ignore all 
> > `OMPDeclareMapperDecl`s in inner scopes, which are already found in 
> > previous calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.
> > 
> > I also found that the declare reduction lookup has the same problem. I'll 
> > push out a similar fix for the declare reduction later.
> I don't think this is the correct behavior. For user-defined reductions, the 
> standard says "This match is done by means of a name lookup in the base 
> language." It means we should use the lookup rules of C/C++. For mapper, 
> seems to me, we also should completely rely on the visibility/accessibility 
> rules used by C/C++.
Again, thanks for your quick response!

```
{
  #pragma omp declare mapper(id: struct S s) (s.a)
  {
#pragma omp declare mapper(id: struct SS ss) (ss.b)
struct S kk;
#pragma omp target map(mapper(id), tofrom: kk)
{}
  }
}
```

If I don't add this code, the above code will report error that it cannnot find 
a mapper with name `id` for type `struct S`, because it can only find the 
second mapper for type `struct SS`. This doesn't look like correct behavior to 
me.

I think we are still following the lookup rules of C/C++ with this fix. It's 
because for declare mapper and reduction, we call `LookupParsedName` multiple 
times on different scopes. In other cases, `LookupParsedName` is always called 
once. Because of this difference, I think this fix is appropriate. What is your 
thought?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > Why do we need special processing of the mapper here?
> > > > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s 
> > > > with the same name (the same as declare reduction lookup), and thus it 
> > > > goes through all scopes from the innermost to the outtermost.
> > > > 
> > > > Then it looks up a parent scope S (e.g., the outter {} in the following 
> > > > example), all `OMPDeclareMapperDecl`s declared in the children scopes 
> > > > of S will appear in the range between `IdResolver.begin(Name)` and 
> > > > `IdResolver.end()`. Also, the `declare mapper(id: struct S s)` will 
> > > > appear before `omp declare mapper(id: struct SS ss)`. This can cause 
> > > > the lookup function to ignore later `omp declare mapper(id: struct SS 
> > > > ss)` declared in the outter scope. As a result, we may not find the 
> > > > corrent mapper.
> > > > 
> > > > ```
> > > > {
> > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > >   {
> > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > ...
> > > >   }
> > > > }
> > > > ```
> > > > 
> > > > To fix this problem, the purpose of this part of code is to ignore all 
> > > > `OMPDeclareMapperDecl`s in inner scopes, which are already found in 
> > > > previous calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.
> > > > 
> > > > I also found that the declare reduction lookup has the same problem. 
> > > > I'll push out a similar fix for the declare reduction later.
> > > I don't think this is the correct behavior. For user-defined reductions, 
> > > the standard says "This match is done by means of a name lookup in the 
> > > base language." It means we should use the lookup rules of C/C++. For 
> > > mapper, seems to me, we also should completely rely on the 
> > > visibility/accessibility rules used by C/C++.
> > Again, thanks for your quick response!
> > 
> > ```
> > {
> >   #pragma omp declare mapper(id: struct S s) (s.a)
> >   {
> > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > struct S kk;
> > #pragma omp target map(mapper(id), tofrom: kk)
> > {}
> >   }
> > }
> > ```
> > 
> > If I don't add this code, the above code will report error that it cannnot 
> > find a mapper with name `id` for type `struct S`, because it can only find 
> > the second mapper for type `struct SS`. This doesn't look like correct 
> > behavior to me.
> > 
> > I think we are still following the lookup rules of C/C++ with this fix. 
> > It's because for declare mapper and reduction, we call `LookupParsedName` 
> > multiple times on different scopes. In other cases, `LookupParsedName` is 
> > always called once. Because of this difference, I think this fix is 
> > appropriate. What is your thought?
> No, in your case we don't. According to the C/C++ rules, if the variable is 
> redeclared, the latest declaration is used. The same rule must be applied to 
> the mapper (according to the standard "The visibility and accessibility of 
> this declaration are the same as those of a variable declared at the same 
> point in the program.")
> I think that the code should fail in this case, because you would the error 
> message in case of the variables declarations with the same names in those 
> scopes.
Hi Alexey,

Thanks for your quick response! I don't think it's redeclared in this case, 
because a mapper has two properties: name and type, just as declare reduction. 
Only when both name and type are the same, it should be considered as 
redeclaration.

If we consider the above example as redeclaration of a mapper, then we can 
always just call `LookupParsedName` once to find the most relevant 
mapper/reductor. Then why do you need to search reductors in a while loop in 
`buildDeclareReductionRef`?

Also, the following example will be correct using the original lookup 
functions, without my fix:

```
{
  #pragma omp declare mapper(id: struct S s) (s.a)
#pragma omp declare mapper(id: struct SS ss) (ss.b)
struct S kk;
#pragma omp target map(mapper(id), tofrom: kk)
{}
}
```

If we consider the second mapper as a redeclaration of the first one, this 
should fail as well. What do you think?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > Why do we need special processing of the mapper here?
> > > > > > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s 
> > > > > > with the same name (the same as declare reduction lookup), and thus 
> > > > > > it goes through all scopes from the innermost to the outtermost.
> > > > > > 
> > > > > > Then it looks up a parent scope S (e.g., the outter {} in the 
> > > > > > following example), all `OMPDeclareMapperDecl`s declared in the 
> > > > > > children scopes of S will appear in the range between 
> > > > > > `IdResolver.begin(Name)` and `IdResolver.end()`. Also, the `declare 
> > > > > > mapper(id: struct S s)` will appear before `omp declare mapper(id: 
> > > > > > struct SS ss)`. This can cause the lookup function to ignore later 
> > > > > > `omp declare mapper(id: struct SS ss)` declared in the outter 
> > > > > > scope. As a result, we may not find the corrent mapper.
> > > > > > 
> > > > > > ```
> > > > > > {
> > > > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > > > >   {
> > > > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > > > ...
> > > > > >   }
> > > > > > }
> > > > > > ```
> > > > > > 
> > > > > > To fix this problem, the purpose of this part of code is to ignore 
> > > > > > all `OMPDeclareMapperDecl`s in inner scopes, which are already 
> > > > > > found in previous calls to `LookupParsedName()` from 
> > > > > > `buildUserDefinedMapperRef`.
> > > > > > 
> > > > > > I also found that the declare reduction lookup has the same 
> > > > > > problem. I'll push out a similar fix for the declare reduction 
> > > > > > later.
> > > > > I don't think this is the correct behavior. For user-defined 
> > > > > reductions, the standard says "This match is done by means of a name 
> > > > > lookup in the base language." It means we should use the lookup rules 
> > > > > of C/C++. For mapper, seems to me, we also should completely rely on 
> > > > > the visibility/accessibility rules used by C/C++.
> > > > Again, thanks for your quick response!
> > > > 
> > > > ```
> > > > {
> > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > >   {
> > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > struct S kk;
> > > > #pragma omp target map(mapper(id), tofrom: kk)
> > > > {}
> > > >   }
> > > > }
> > > > ```
> > > > 
> > > > If I don't add this code, the above code will report error that it 
> > > > cannnot find a mapper with name `id` for type `struct S`, because it 
> > > > can only find the second mapper for type `struct SS`. This doesn't look 
> > > > like correct behavior to me.
> > > > 
> > > > I think we are still following the lookup rules of C/C++ with this fix. 
> > > > It's because for declare mapper and reduction, we call 
> > > > `LookupParsedName` multiple times on different scopes. In other cases, 
> > > > `LookupParsedName` is always called once. Because of this difference, I 
> > > > think this fix is appropriate. What is your thought?
> > > No, in your case we don't. According to the C/C++ rules, if the variable 
> > > is redeclared, the latest declaration is used. The same rule must be 
> > > applied to the mapper (according to the standard "The visibility and 
> > > accessibility of this declaration are the same as those of a variable 
> > > declared at the same point in the program.")
> > > I think that the code should fail in this case, because you would the 
> > > error message in case of the variables declarations with the same names 
> > > in those scopes.
> > Hi Alexey,
> > 
> > Thanks for your quick response! I don't think it's redeclared in this case, 
> > because a mapper has two properties: name and type, just as declare 
> > reduction. Only when both name and type are the same, it should be 
> > considered as redeclaration.
> > 
> > If we consider the above example as redeclaration of a mapper, then we can 
> > always just call `LookupParsedName` once to find the most relevant 
> > mapper/reductor. Then why do you need to search reductors in a while loop 
> > in `buildDeclareReductionRef`?
> > 
> > Also, the following example will be correct using the original lookup 
> > functions, without my fix:
> > 
> > ```
> > {
> >   #pragma omp declare mapper(id: struct S s) (s.a)
> > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > struct S kk;
> > #pragma omp target map(mapper(id), tofrom: kk)
> > {}
> > }
> > ```
> > 
> > If we consider the second mapper as a redeclaration of the first one, this 
> > should fail as well. What do you think?
> The standard clearly states that "The visibil

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh added a reviewer: kkwli0.
lildmh marked 4 inline comments as done.
lildmh added inline comments.



Comment at: lib/Parse/ParseOpenMP.cpp:2144
+parseMapType(*this, Data);
 }
 if (Data.MapType == OMPC_MAP_unknown) {

kkwli0 wrote:
> Although it is an error situation, will we have different behavior?
> 
> ```
> ... map(xclose, to: x)
> ```
> 
> Previously, it always parses both modifier and type.  After the change, the 
> call of `parseMapType` is skipped.  If it `OMPC_MAP_unknown`, 
> `IsMapTypeImplicit` is set.
Hi Kelvin,

Thanks a lot for the review! It will not change the behavior of parsing 
modifiers other than mapper. `parseMapTypeModifiers` will only return true when 
it finds a invalid mapper for now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 186742.
lildmh added a comment.

1. Move mapper related info to `OMPMappableExprListClause`, so that `to` and 
`from` clauses can utilize the same infrastructure as well (real support for 
them will be in another patch);
2. Combine the function parameters for `declare mapper` and `declare 
reduction`, to reduce the function parameter number of `ActOnOMPVarListClause`;
3. Implement ADL for mapper, and remove mapper lookups in SemaLookup.cpp;
4. Didn't combine modifier related info into a structure, because for `to` and 
`from` clauses will only have possible `mapper` modifier, not `close` and 
`always`;
5. Address typos that Kelvin found;
6. Rebase.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074

Files:
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  test/OpenMP/target_teams_map_messages.cpp

Index: test/OpenMP/target_teams_map_messages.cpp
===
--- test/OpenMP/target_teams_map_messages.cpp
+++ test/OpenMP/target_teams_map_messages.cpp
@@ -454,7 +454,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
@@ -529,7 +529,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
Index: test/OpenMP/target_teams_distribute_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
@@ -271,7 +271,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added a comment.

Hi Alexey,

Again thanks for your review! The codegen completely ignores any mapper related 
info for now, so it should not crash map clause codegen. It also passed the 
regression test, so map clause codegen should be fine.




Comment at: include/clang/AST/OpenMPClause.h:4193
 ArrayRef MapModifiersLoc,
+NestedNameSpecifierLoc MapperQualifierLoc,
+DeclarationNameInfo MapperIdInfo,

ABataev wrote:
> Also would be good to pack the parameters into the structure.
Among these parameters:
1. 2 of them are for modifiers. Since mapper can also be used in `to` and 
`from` clauses, it is not good to combine mapper info with them.
2. 2 of them are mapper info. I can combine `MapperQualifierLoc` and 
`MapperIdInfo` into a structure. It's not a big saving though (only reduce one 
parameter). Do you want me to do that?
3. 4 of them are number of vars... It seems not a good idea to combine them 
into one structure.
5. The rest are locations. They are kinda all over the place. It doesn't seem a 
good idea to combine them as well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added a comment.

Sure I'll add a codegen test with mapper. Thanks!




Comment at: include/clang/AST/OpenMPClause.h:4193
 ArrayRef MapModifiersLoc,
+NestedNameSpecifierLoc MapperQualifierLoc,
+DeclarationNameInfo MapperIdInfo,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Also would be good to pack the parameters into the structure.
> > Among these parameters:
> > 1. 2 of them are for modifiers. Since mapper can also be used in `to` and 
> > `from` clauses, it is not good to combine mapper info with them.
> > 2. 2 of them are mapper info. I can combine `MapperQualifierLoc` and 
> > `MapperIdInfo` into a structure. It's not a big saving though (only reduce 
> > one parameter). Do you want me to do that?
> > 3. 4 of them are number of vars... It seems not a good idea to combine them 
> > into one structure.
> > 5. The rest are locations. They are kinda all over the place. It doesn't 
> > seem a good idea to combine them as well.
> 1. The same structure must be used for `to` and `from` clauses, not a problem.
> 2-4. you can combine it with the number of vars and locations into one 
> structure, no?
None of these locations are for mapper, so I think it's not good to combine 
them with mapper.
Those numbers (`NumVars`, `NumUniqueDeclarations`, `NumComponentLists`, 
`NumComponents`) are not for mapper either. `NumVars` can be viewed as 
partially for mapper, but its main purpose is for the number of list items in 
map clause. So logically, I think they should not be combined with mapper.
What do you think?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 186912.
lildmh added a comment.

Introduce a structure `OMPMappableExprListSizeTy` within 
`OMPMappableExprListClause` to aggregate all 4 sizes needed by such clause, and 
thus reduce the number of parameters when creating a map clause. This can also 
be used by other similar clauses. I'll have another patch to let other clauses 
to use this structure as well.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074

Files:
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  test/OpenMP/target_teams_map_messages.cpp

Index: test/OpenMP/target_teams_map_messages.cpp
===
--- test/OpenMP/target_teams_map_messages.cpp
+++ test/OpenMP/target_teams_map_messages.cpp
@@ -454,7 +454,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
@@ -529,7 +529,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
Index: test/OpenMP/target_teams_distribute_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
@@ -271,7 +271,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
Index: test/OpenMP/target_teams_distribute_parallel

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: include/clang/AST/OpenMPClause.h:3682-3685
+  OpenMPClauseKind K, SourceLocation StartLoc, SourceLocation LParenLoc,
+  SourceLocation EndLoc, OMPMappableExprListSizeTy Sizes,
+  NestedNameSpecifierLoc *MapperQualifierLocP = nullptr,
+  DeclarationNameInfo *MapperIdInfoP = nullptr)

ABataev wrote:
> I think it is worth to add `SourceLocation StartLoc`, `SourceLocation 
> LParenLoc`, `SourceLocation EndLoc`, to `OMPMappableExprListSizeTy`. Of 
> course, you need to rename the structure, something like 
> `OMPMappableClauseData` is good enough. Or you can pack them into a different 
> structure.
I put `StartLoc`, `LParenLoc`, `EndLoc` into another struct 
`OMPMappableExprListLocTy`. I didn't combine them with 
`OMPMappableExprListSizeTy`, because some fuctions only use one of them, and 
some other functions use both of them.

Also modify `to`, `from`, `is_device`, and `use_device` clauses to use the same 
interfaces.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58074/new/

https://reviews.llvm.org/D58074



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to and from clauses with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
lildmh added reviewers: ABataev, hfinkel, Meinersbur, kkwli0.
lildmh added a project: OpenMP.
Herald added subscribers: cfe-commits, jdoerfert, guansong.
Herald added a project: clang.

This patch implements the parsing and sema support for OpenMP to and from 
clauses with potential user-defined mappers attached. User defined mapper is a 
new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit 
associated mapper, which instructs the compiler to generate and use customized 
mapping functions. An example is shown below:

  struct S { int len; int *d; };
  #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
  struct S ss;
  #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' 
to map ss to device


Repository:
  rC Clang

https://reviews.llvm.org/D58523

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -29,7 +29,7 @@
 #pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
 #pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
 
-#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal OpenMP user-defined mapper identifier}}
 #pragma omp declare mapper(id1: vec v) map(v.len, temp) // expected-error {{only variable v is allowed in map clauses of this 'omp declare mapper' directive}}
 #pragma omp declare mapper(default : vec kk) map(kk.data[0:2])  // expected-note {{previous definition is here}}
 #pragma omp declare mapper(vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'default'}}
@@ -74,9 +74,9 @@
   {}
 #pragma omp target map(mapper(ab) :vv)  // expected-error {{missing map type}} expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}}
   {}
-#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
-#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
 #pragma omp target map(mapper(aa) :vv)  // expected-error {{missing map type}}
   {}
@@ -86,6 +86,32 @@
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
+
+#pragma omp target update to(mapper)// expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper()   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper:vv) // expected-error {{expected '(' after 'mapper'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(:vv)// expected-error {{illegal OpenMP user-defined mapper identifier}} expected-err

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to and from clauses with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 12 inline comments as done.
lildmh added inline comments.



Comment at: lib/AST/OpenMPClause.cpp:1469
 
 void OMPClausePrinter::VisitOMPFromClause(OMPFromClause *Node) {
   if (!Node->varlist_empty()) {

ABataev wrote:
> Better to split this patch into 2: one for `to` clause and another one for 
> `from` clause
Hi Alexey,

Thanks for the quick review! The code for `to` and `from` clauses are almost 
identical, so I prefer to have them in the same patch. Besides I don't have 
commit privilege, so it causes more time to me to have multiple patches. But if 
you think it's crucial to split it. I can do it. What do you think?



Comment at: lib/Sema/SemaOpenMP.cpp:13061
 MapperIdScopeSpec.getWithLocInContext(SemaRef.Context), MapperId,
-/*ADL=*/false, /*Overloaded=*/true, URS.begin(), URS.end());
+/*ADL=*/true, /*Overloaded=*/true, URS.begin(), URS.end());
   }

ABataev wrote:
> Better to fix this in a separate patch.
I can do that.



Comment at: lib/Sema/SemaOpenMP.cpp:13356
 
-  // Try to find the associated user-defined mapper.
-  ExprResult ER = buildUserDefinedMapperRef(
-  SemaRef, DSAS->getCurScope(), *MapperIdScopeSpec, *MapperId,
-  Type.getCanonicalType(), UnresolvedMapper);
-  if (ER.isInvalid())
-continue;
-  MVLI.UDMapperList.push_back(ER.get());
-} else {
-  MVLI.UDMapperList.push_back(nullptr);
 }
 

ABataev wrote:
> Are you sure about this change? This might trigger some asserts.
Yes. The original code before the mapper patch is like this. By moving it out, 
`to` and `from` clauses will also call `buildUserDefinedMapperRef` check the 
mapper as well.



Comment at: lib/Sema/SemaOpenMP.cpp:13413
 
-  // If the identifier of user-defined mapper is not specified, it is 
"default".
-  if (!MapperId.getName() || MapperId.getName().isEmpty()) {

ABataev wrote:
> Again, better to do this in a separate patch
This modification is for `to` and `from` clauses, so they also have a default 
mapper name. I think it is appropriate to have this piece in this patch.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to and from clauses with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 187869.
lildmh marked 3 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -29,7 +29,7 @@
 #pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
 #pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
 
-#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal OpenMP user-defined mapper identifier}}
 #pragma omp declare mapper(id1: vec v) map(v.len, temp) // expected-error {{only variable v is allowed in map clauses of this 'omp declare mapper' directive}}
 #pragma omp declare mapper(default : vec kk) map(kk.data[0:2])  // expected-note {{previous definition is here}}
 #pragma omp declare mapper(vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'default'}}
@@ -74,9 +74,9 @@
   {}
 #pragma omp target map(mapper(ab) :vv)  // expected-error {{missing map type}} expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}}
   {}
-#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
-#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
 #pragma omp target map(mapper(aa) :vv)  // expected-error {{missing map type}}
   {}
@@ -86,6 +86,32 @@
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
+
+#pragma omp target update to(mapper)// expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper()   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper:vv) // expected-error {{expected '(' after 'mapper'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(:vv)// expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(aa :vv) // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(N2:: :vv)   // expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pra

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 187958.
lildmh retitled this revision from "[OpenMP 5.0] Parsing/sema support for to 
and from clauses with mapper modifier" to "[OpenMP 5.0] Parsing/sema support 
for to clause with mapper modifier".
lildmh edited the summary of this revision.
lildmh added a comment.

get rid of the from clause part.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -29,7 +29,7 @@
 #pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
 #pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
 
-#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal OpenMP user-defined mapper identifier}}
 #pragma omp declare mapper(id1: vec v) map(v.len, temp) // expected-error {{only variable v is allowed in map clauses of this 'omp declare mapper' directive}}
 #pragma omp declare mapper(default : vec kk) map(kk.data[0:2])  // expected-note {{previous definition is here}}
 #pragma omp declare mapper(vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'default'}}
@@ -74,9 +74,9 @@
   {}
 #pragma omp target map(mapper(ab) :vv)  // expected-error {{missing map type}} expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}}
   {}
-#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
-#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
 #pragma omp target map(mapper(aa) :vv)  // expected-error {{missing map type}}
   {}
@@ -86,6 +86,19 @@
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
+
+#pragma omp target update to(mapper)// expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper()   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper:vv) // expected-error {{expected '(' after 'mapper'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(:vv)// expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(aa :vv) // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(N2:: :vv) 

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:13195
-  } else {
-MVLI.UDMapperList.push_back(nullptr);
   }

ABataev wrote:
> Is this correct for `from` clause?
Yes, it's correct for `from`, which will never use `MVLI.UDMapperList`. 
Regression test is also correct.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 187964.
lildmh marked 4 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -29,7 +29,7 @@
 #pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
 #pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
 
-#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal OpenMP user-defined mapper identifier}}
 #pragma omp declare mapper(id1: vec v) map(v.len, temp) // expected-error {{only variable v is allowed in map clauses of this 'omp declare mapper' directive}}
 #pragma omp declare mapper(default : vec kk) map(kk.data[0:2])  // expected-note {{previous definition is here}}
 #pragma omp declare mapper(vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'default'}}
@@ -74,9 +74,9 @@
   {}
 #pragma omp target map(mapper(ab) :vv)  // expected-error {{missing map type}} expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}}
   {}
-#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
-#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
 #pragma omp target map(mapper(aa) :vv)  // expected-error {{missing map type}}
   {}
@@ -86,6 +86,19 @@
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
+
+#pragma omp target update to(mapper)// expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper()   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper:vv) // expected-error {{expected '(' after 'mapper'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(:vv)// expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(aa :vv) // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(N2:: :vv)   // expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pra

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Thanks a lot!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58523: [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 187970.
lildmh added a comment.

Rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58523/new/

https://reviews.llvm.org/D58523

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -29,7 +29,7 @@
 #pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
 #pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
 
-#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal OpenMP user-defined mapper identifier}}
 #pragma omp declare mapper(id1: vec v) map(v.len, temp) // expected-error {{only variable v is allowed in map clauses of this 'omp declare mapper' directive}}
 #pragma omp declare mapper(default : vec kk) map(kk.data[0:2])  // expected-note {{previous definition is here}}
 #pragma omp declare mapper(vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'default'}}
@@ -74,9 +74,9 @@
   {}
 #pragma omp target map(mapper(ab) :vv)  // expected-error {{missing map type}} expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}}
   {}
-#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N2::) :vv)// expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
-#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp target map(mapper(N1::) :vv)// expected-error {{illegal OpenMP user-defined mapper identifier}}
   {}
 #pragma omp target map(mapper(aa) :vv)  // expected-error {{missing map type}}
   {}
@@ -86,6 +86,19 @@
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
+
+#pragma omp target update to(mapper)// expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper()   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper:vv) // expected-error {{expected '(' after 'mapper'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(:vv)// expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(aa :vv) // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(N2:: :vv)   // expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp 

[PATCH] D58638: [OpenMP 5.0] Parsing/sema support for from clause with mapper modifier

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
lildmh added reviewers: ABataev, hfinkel, Meinersbur, kkwli0.
lildmh added a project: OpenMP.
Herald added subscribers: cfe-commits, jdoerfert, guansong.
Herald added a project: clang.

This patch implements the parsing and sema support for OpenMP from clause with 
potential user-defined mappers attached. User defined mapper is a new feature 
in OpenMP 5.0. A from clause can have an explicit or implicit associated 
mapper, which instructs the compiler to generate and use customized mapping 
functions. An example is shown below:

  struct S { int len; int *d; };
  #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len])
  struct S ss;
  #pragma omp target update from(mapper(id): ss) // use the mapper with name 
'id' to map ss from device


Repository:
  rC Clang

https://reviews.llvm.org/D58638

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/OpenMPKinds.def
  include/clang/Basic/OpenMPKinds.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -99,6 +99,19 @@
 #pragma omp target update to(mapper(aa) a:vv)   // expected-warning {{missing ':' after ) - ignoring}}
 #pragma omp target update to(mapper(aa):vv)
 #pragma omp target update to(mapper(N1::stack::id) :vv)
+
+#pragma omp target update from(mapper)  // expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper() // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper:vv)   // expected-error {{expected '(' after 'mapper'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(:vv)  // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(aa :vv)   // expected-error {{expected ')'}} expected-note {{to match this '('}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(N2:: :vv) // expected-error {{use of undeclared identifier 'N2'}} expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(N1:: :vv) // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(N1::aa) :vv)  // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(ab):vv)   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(aa) a:vv) // expected-warning {{missing ':' after ) - ignoring}}
+#pragma omp target update from(mapper(aa):vv)
+#pragma omp target update from(mapper(N1::stack::id) :vv)
 }
 #pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'id'}}
   }
Index: test/OpenMP/declare_mapper_messages.c
===
--- test/OpenMP/declare_mapper_messages.c
+++ test/OpenMP/declare_mapper_messages.c
@@ -58,6 +58,15 @@
 #pragma omp target update to(mapper(aa :vv) // expected-error {{expected ')'}} e

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 202790.
lildmh edited the summary of this revision.
lildmh added a comment.

Implement the new mapper codegen scheme


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-l

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 202926.
lildmh added a comment.

Address Alexey's comment about mapping between function and user-defined mappers


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %cla

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 203438.
lildmh added a comment.

Use __tgt instead of __kmpc for mapper runtime function names


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopen

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8729
+/// \code
+/// void .omp_mapper...(void *rt_mapper_handle,
+///   void *base, void *begin,

ABataev wrote:
> This function looks like the universal one, regardless of the type 
> `` specifics. Do we really need to generate it for each particular 
> type and mapper? Or we could use the same function for all types/mappers?
I think we need a particular mapper function for each type and mapper, because 
the code generated within the mapper function depends on what type and what 
mapper it is.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8729
+/// \code
+/// void .omp_mapper...(void *rt_mapper_handle,
+///   void *base, void *begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > This function looks like the universal one, regardless of the type 
> > > `` specifics. Do we really need to generate it for each 
> > > particular type and mapper? Or we could use the same function for all 
> > > types/mappers?
> > I think we need a particular mapper function for each type and mapper, 
> > because the code generated within the mapper function depends on what type 
> > and what mapper it is.
> Hmm, maybe I'm wrong but I don't see significant mapper or type-specific 
> dependencies in this mapper function. It uses the pointer to type and size of 
> the type, but this information can be generalized, I think. Could you point 
> the lines of code that are type and mapper specific?
Code between line 8857-8965 is type and mapper specific. For instance, 
`generateAllInforForMapper` depends on the map clauses associated with the 
mapper and the internal structure of struct/class type, and generates 
difference code as a result. `BasePointers.size()` also depends on the above 
things.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8729
+/// \code
+/// void .omp_mapper...(void *rt_mapper_handle,
+///   void *base, void *begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > This function looks like the universal one, regardless of the type 
> > > > > `` specifics. Do we really need to generate it for each 
> > > > > particular type and mapper? Or we could use the same function for all 
> > > > > types/mappers?
> > > > I think we need a particular mapper function for each type and mapper, 
> > > > because the code generated within the mapper function depends on what 
> > > > type and what mapper it is.
> > > Hmm, maybe I'm wrong but I don't see significant mapper or type-specific 
> > > dependencies in this mapper function. It uses the pointer to type and 
> > > size of the type, but this information can be generalized, I think. Could 
> > > you point the lines of code that are type and mapper specific?
> > Code between line 8857-8965 is type and mapper specific. For instance, 
> > `generateAllInforForMapper` depends on the map clauses associated with the 
> > mapper and the internal structure of struct/class type, and generates 
> > difference code as a result. `BasePointers.size()` also depends on the 
> > above things.
> Most of these data can be passed as parameters to the function. It would be 
> good, if we could move this function to the libomptaret library and reduce 
> the number of changes (and, thus, complexity) of the compiler itself. It is 
> always easier to review and to maintain the source code written in C/C++ 
> rather than the changes in the compiler codegen. Plus, it may reduce the size 
> of the final code significantly, I assume. I would appreciate it if you would 
> try to move this function to libomptarget.
Hi Alexey, I don't think libomptarget can do this efficiently. For example,

```
class C {
  int a;
  double *b
}

#pragma omp declare mapper(C c) map(c.a, c.b[0:1])
```

The codegen can directly know there are 2 components (c.a, c.b[0]) in this 
mapper function (3 actually when we count the pointer), and it can also know 
the size, starting address, map type, etc. about these components. Passing all 
these information to libomptarget seems to be a bad idea. Or did I get your 
idea wrong?



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8729
+/// \code
+/// void .omp_mapper...(void *rt_mapper_handle,
+///   void *base, void *begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > This function looks like the universal one, regardless of the 
> > > > > > > type `` specifics. Do we really need to generate it 
> > > > > > > for each particular type and mapper? Or we could use the same 
> > > > > > > function for all types/mappers?
> > > > > > I think we need a particular mapper function for each type and 
> > > > > > mapper, because the code generated within the mapper function 
> > > > > > depends on what type and what mapper it is.
> > > > > Hmm, maybe I'm wrong but I don't see significant mapper or 
> > > > > type-specific dependencies in this mapper function. It uses the 
> > > > > pointer to type and size of the type, but this information can be 
> > > > > generalized, I think. Could you point the lines of code that are type 
> > > > > and mapper specific?
> > > > Code between line 8857-8965 is type and mapper specific. For instance, 
> > > > `generateAllInforForMapper` depends on the map clauses associated with 
> > > > the mapper and the internal structure of struct/class type, and 
> > > > generates difference code as a result. `BasePointers.size()` also 
> > > > depends on the above things.
> > > Most of these data can be passed as parameters to the function. It would 
> > > be good, if we could move this function to the libomptaret library and 
> > > reduce the number of changes (and, thus, complexity) of the compiler 
> > > itself. It is always easier to review and to maintain the source code 
> > > written in C/C++ rather than the changes in the compiler codegen. Plus, 
> > > it may reduce the size of the final code significantly, I assume. I would 
> > > appreciate it if you would try to move this function to libomptarget.
> > Hi Alexey, I don't think libomptarget can do this efficiently. For example,
> > 
> > ```
> > class C {
> >   int a;
> >   double *b
> > }
> > 
> > #pragma omp declare mapper(C c) map(c.a, c.b[0:1])
> > ```
> > 
> > The codegen can directly know there are 2 components (c.a, c.b[0]) in this 
> > mapper function (3 actually when we count the pointer), and it can also 
> > know the size, starting address, map type, etc. about these components. 
> > Passing all these information to libomptarget seems to be a bad idea. Or 
> > did I get your idea wrong?
> > 
> Yes, I understand this. But can we pass some additional parameters to this 
> function so we don't need to generate a unique copy of almost the same 
> function for all types/mappers? 
For different types/mappers, the skeleton of mapper functions are similar 
(i.e., the things outlined in the comment here). I would say most other code is 
unique, for instance, the code to prepare parameters of call to 
`__tgt_push_mapper_component`. These code should be much more compared with the 
skeleton shown here. I cannot think of a way to reduce the code by passing more 
parameters to this function. Please let me know if you have some suggestions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 205647.
lildmh marked 3 inline comments as done.
lildmh added a comment.

Fix mapper function name mangling


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> Currently `currentComponent` is generated by the compiler. But can we instead 
> pass this data as an extra parameter to this `omp_mapper` function.
Emm, I think this scheme will be very difficult and inefficient. If we pass 
components as an argument of `omp_mapper` function, it means that the runtime 
needs to generate all components related to a map clause. I don't think the 
runtime is able to do that efficiently. On the other hand, in the current 
scheme, these components are naturally generated by the compiler, and the 
runtime only needs to know the base pointer, pointer, type, size. etc.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8740
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,
+///arg_size, arg_type);

ABataev wrote:
> I don't see this part of logic in the code. Could you show me where is it 
> exactly?
This part doesn't exist in this patch. Currently we don't really look up the 
mapper for any mapped variable/array/etc. The next patch will add the code to 
look up the specified mapper for every map clause, and get the mapper function 
for them correspondingly.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8785
+  std::string Name = getName({"omp_mapper", Ty.getAsString(), D->getName()});
+  std::replace(Name.begin(), Name.end(), ' ', '_');
+  auto *Fn = llvm::Function::Create(FnTy, llvm::GlobalValue::InternalLinkage,

ABataev wrote:
> Bad idea to do this. Better to use something like this:
> ```
> SmallString<256> TyStr;
> llvm::raw_svector_ostream Out(TyStr);
> CGM.getCXXABI().getMangleContext().mangleTypeName(Ty, Out);
> 
> ```
> 
Sounds good. Thanks!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 205785.
lildmh marked 9 inline comments as done.
lildmh added a comment.

Address Alexey's comments


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Currently `currentComponent` is generated by the compiler. But can we 
> > > instead pass this data as an extra parameter to this `omp_mapper` 
> > > function.
> > Emm, I think this scheme will be very difficult and inefficient. If we pass 
> > components as an argument of `omp_mapper` function, it means that the 
> > runtime needs to generate all components related to a map clause. I don't 
> > think the runtime is able to do that efficiently. On the other hand, in the 
> > current scheme, these components are naturally generated by the compiler, 
> > and the runtime only needs to know the base pointer, pointer, type, size. 
> > etc.
> With the current scheme, we may end with the code blowout. We need to 
> generate very similar code for different types and variables. The worst thing 
> here is that we will be unable to optimize this huge amount of code because 
> the codegen relies on the runtime functions and the code cannot be inlined. 
> That's why I would like to move as much as possible code to the runtime 
> rather than to emit it in the compiler. 
I understand your concerns. I think this is the best we can do right now.

The most worrisome case will be when we have nested mappers within each other. 
In this case, a mapper function will call another mapper function. We can 
inline the inner mapper functions in this scenario, so that these mapper 
function can be properly optimized. As a result, I think the performance should 
be fine.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8866-8867
+  createRuntimeFunction(OMPRTL__tgt_mapper_num_components), 
OffloadingArgs);
+  llvm::Value *ShiftedPreviousSize =
+  MapperCGF.Builder.CreateShl(PreviousSize, 
MapperCGF.Builder.getInt64(48));
+

ABataev wrote:
> I don't like this code very much! It hides the logiс ща the MEMBER_OF flag 
> deep inside and it is going to be very hard to update it in future if there 
> are some changes in the flags.
Add a function to calculate this offset. Also modify another existing place 
using the hard coded number 48.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D59474#1589464 , @ABataev wrote:

> In D59474#1561161 , @lildmh wrote:
>
> > Change the type of size from `size_t` to `int64_t`, and rebase
>
>
> Lingda, could you rebase it again? Thanks.


Sure, I'll do it next week, since I'm on vacation and don't have access to my 
desktop.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 211278.
lildmh added a comment.
Herald added a reviewer: jdoerfert.

Rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-ta

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh added inline comments.



Comment at: lib/CodeGen/CGDecl.cpp:2533
+ CodeGenFunction *CGF) {
+  if (!LangOpts.OpenMP || LangOpts.OpenMPSimd ||
+  (!LangOpts.EmitAllDecls && !D->isUsed()))

ABataev wrote:
> Why do we need to emit it for simd only mode?
This code is not emitting mapper for simd only mode.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7116-7124
+  /// Get the offset of the OMP_MAP_MEMBER_OF field.
+  static unsigned getFlagMemberOffset() {
+unsigned Offset = 0;
+for (uint64_t Remain = OMP_MAP_MEMBER_OF; !(Remain & 1);
+ Remain = Remain >> 1)
+  Offset++;
+return Offset;

ABataev wrote:
> Maybe it is better to define a constant `constexpr uint64_t 
> OMP_MEMBER_OF_RANK = 48` and then deduce `OMP_MAP_MEMBER_OF` as 
> `~((1

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 211333.
lildmh marked 4 inline comments as done.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 3 inline comments as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7116-7124
+  /// Get the offset of the OMP_MAP_MEMBER_OF field.
+  static unsigned getFlagMemberOffset() {
+unsigned Offset = 0;
+for (uint64_t Remain = OMP_MAP_MEMBER_OF; !(Remain & 1);
+ Remain = Remain >> 1)
+  Offset++;
+return Offset;

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Maybe it is better to define a constant `constexpr uint64_t 
> > > OMP_MEMBER_OF_RANK = 48` and then deduce `OMP_MAP_MEMBER_OF` as 
> > > `~((1< > In libomptarget, the same way is used to define 
> > `OMP_TGT_MAPTYPE_MEMBER_OF`: `OMP_TGT_MAPTYPE_MEMBER_OF   = 
> > 0x`. So I think they should stay the same. Btw, the number 
> > 48 is directly used in libomptarget now, which may need to change in the 
> > future.
> > 
> > In your code, it assumes bits higher than 48 are all `OMP_MAP_MEMBER_OF`, 
> > which may not be true in the future. My code here is more universal, 
> > although it does not look great. What do you think?
> You can apply a mask to drop some of the most significant bits if required. 
> My code looks much cleaner it would be good to have the same code in 
> libomptarget too.
> But it is up to you what to do here.
> 
Maybe let's keep it this way in this patch, then we modify both places in a 
further patch?



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8116
+MapFlagsArrayTy &Types) const {
+// FIXME: MSVC 2013 seems to require this-> to find member CurDir.
+assert(this->CurDir.is() &&

ABataev wrote:
> ABataev wrote:
> > AFAIK, LLVM has dropped support for msvc 2013, do we still need this?
> Ping.
I'm okay either way. I guess it doesn't hurt to keep it?



Comment at: lib/CodeGen/CGOpenMPRuntime.h:2110
+  /// Emit code for the user defined mapper construct.
+  void emitUserDefinedMapper(const OMPDeclareMapperDecl *D,
+ CodeGenFunction *CGF = nullptr) override;

ABataev wrote:
> I think you can drop this function here if the original function is not 
> virtual
The function for simd only mode includes a `llvm_unreachable`, so I think it's 
still needed as a virtual function above


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 211589.
lildmh added a comment.

Get rid of MSVC requirement of this, and a virtual function


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:2110
+  /// Emit code for the user defined mapper construct.
+  void emitUserDefinedMapper(const OMPDeclareMapperDecl *D,
+ CodeGenFunction *CGF = nullptr) override;

ABataev wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > I think you can drop this function here if the original function is not 
> > > > virtual
> > > The function for simd only mode includes a `llvm_unreachable`, so I think 
> > > it's still needed as a virtual function above
> > It is better to reduce number of virtual functions, if possible.
> What about virtual function?
Since `emitUserDefinedMapper` here overrides the same function in 
`CGOpenMPRuntime`, I think `emitUserDefinedMapper` of `CGOpenMPRuntime` needs 
to be defined as `virtual`?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:2110
+  /// Emit code for the user defined mapper construct.
+  void emitUserDefinedMapper(const OMPDeclareMapperDecl *D,
+ CodeGenFunction *CGF = nullptr) override;

lildmh wrote:
> ABataev wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > I think you can drop this function here if the original function is 
> > > > > not virtual
> > > > The function for simd only mode includes a `llvm_unreachable`, so I 
> > > > think it's still needed as a virtual function above
> > > It is better to reduce number of virtual functions, if possible.
> > What about virtual function?
> Since `emitUserDefinedMapper` here overrides the same function in 
> `CGOpenMPRuntime`, I think `emitUserDefinedMapper` of `CGOpenMPRuntime` needs 
> to be defined as `virtual`?
If you are asking about what virtual function I removed, it is 
`emitUDMapperArrayInitOrDel` of `CGOpenMPRuntime` which is never overrided.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:2110
+  /// Emit code for the user defined mapper construct.
+  void emitUserDefinedMapper(const OMPDeclareMapperDecl *D,
+ CodeGenFunction *CGF = nullptr) override;

ABataev wrote:
> lildmh wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > I think you can drop this function here if the original function 
> > > > > > > is not virtual
> > > > > > The function for simd only mode includes a `llvm_unreachable`, so I 
> > > > > > think it's still needed as a virtual function above
> > > > > It is better to reduce number of virtual functions, if possible.
> > > > What about virtual function?
> > > Since `emitUserDefinedMapper` here overrides the same function in 
> > > `CGOpenMPRuntime`, I think `emitUserDefinedMapper` of `CGOpenMPRuntime` 
> > > needs to be defined as `virtual`?
> > If you are asking about what virtual function I removed, it is 
> > `emitUDMapperArrayInitOrDel` of `CGOpenMPRuntime` which is never overrided.
> I would suggest to not make this virtual too and remove overriden version. It 
> does not help.
If we remove virtual from `emitUserDefinedMapper`, we will have to define it in 
both `CGOpenMPRuntime` and `CGOpenMPSIMDRuntime`, and its definition is 
identical in both places. I don't think that's good software engineering 
practice?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 211794.
lildmh added a comment.

Remove virtual from function declaration


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targ

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.h:815
+  /// code generation.
+  void emitUDMapperArrayInitOrDel(CodeGenFunction &MapperCGF,
+  llvm::Value *Handle, llvm::Value *BasePtr,

ABataev wrote:
> Seems to me, this function is used only in `emitUserDefinedMapper`. I think 
> you can make it static local in the CGOpenMPRuntime.cpp and do not expose it 
> in the interface.
`emitUserDefinedMapper` needs to call `createRuntimeFunction` of 
`CGOpenMPRuntime`, which is private.

Which one do you think is better, make `createRuntimeFunction` public, or have 
`emitUserDefinedMapper` not defined in `CGOpenMPRuntime`? It seems to me that 
they are similar


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 211991.
lildmh added a comment.

Make `emitUDMapperArrayInitOrDel` private


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-tar

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added a comment.

Thanks Alexey! Could you look into the runtime patch D60972 
 then?




Comment at: test/OpenMP/declare_mapper_codegen.cpp:44-48
+// CK0-DAG: store i8* %0, i8** [[HANDLEADDR:%[^,]+]]
+// CK0-DAG: store i8* %1, i8** [[BPTRADDR:%[^,]+]]
+// CK0-DAG: store i8* %2, i8** [[VPTRADDR:%[^,]+]]
+// CK0-DAG: store i64 %3, i{{64|32}}* [[SIZEADDR:%[^,]+]]
+// CK0-DAG: store i64 %4, i64* [[TYPEADDR:%[^,]+]]

ABataev wrote:
> I would not rely on the predetermined indices here, better to use some kind 
> of patterns here just like in other places.
Could you give an example about what you suggest? For instance, some other 
tests I should look into.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: test/OpenMP/declare_mapper_codegen.cpp:44-48
+// CK0-DAG: store i8* %0, i8** [[HANDLEADDR:%[^,]+]]
+// CK0-DAG: store i8* %1, i8** [[BPTRADDR:%[^,]+]]
+// CK0-DAG: store i8* %2, i8** [[VPTRADDR:%[^,]+]]
+// CK0-DAG: store i64 %3, i{{64|32}}* [[SIZEADDR:%[^,]+]]
+// CK0-DAG: store i64 %4, i64* [[TYPEADDR:%[^,]+]]

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > I would not rely on the predetermined indices here, better to use some 
> > > kind of patterns here just like in other places.
> > Could you give an example about what you suggest? For instance, some other 
> > tests I should look into.
> Just like in this test when you're using vars.
Sorry I was not clear before. What do you mean by "predetermined indices" here? 
If you are referring to, for example, `%0` in `store i8* %0, i8** 
[[HANDLEADDR:%[^,]+]]`, I guess there is no way to get rid of `%0` because it 
means the first argument of the function?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: test/OpenMP/declare_mapper_codegen.cpp:44-48
+// CK0-DAG: store i8* %0, i8** [[HANDLEADDR:%[^,]+]]
+// CK0-DAG: store i8* %1, i8** [[BPTRADDR:%[^,]+]]
+// CK0-DAG: store i8* %2, i8** [[VPTRADDR:%[^,]+]]
+// CK0-DAG: store i64 %3, i{{64|32}}* [[SIZEADDR:%[^,]+]]
+// CK0-DAG: store i64 %4, i64* [[TYPEADDR:%[^,]+]]

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > I would not rely on the predetermined indices here, better to use 
> > > > > some kind of patterns here just like in other places.
> > > > Could you give an example about what you suggest? For instance, some 
> > > > other tests I should look into.
> > > Just like in this test when you're using vars.
> > Sorry I was not clear before. What do you mean by "predetermined indices" 
> > here? If you are referring to, for example, `%0` in `store i8* %0, i8** 
> > [[HANDLEADDR:%[^,]+]]`, I guess there is no way to get rid of `%0` because 
> > it means the first argument of the function?
> Yes, I meant those `%0` like registers. Better to mark them as variables in 
> function declaration and use those names in the checks.
Now it's like `define {{.*}}void @.omp_mapper.{{.*}}C.id{{.*}}(i8*, i8*, i8*, 
i64, i64)`, I think you are suggesting something like `define {{.*}}void 
@.omp_mapper.{{.*}}C.id{{.*}}(i8* [[HANDLE:%[^,]+]], i8* [[BPTR:%[^,]+]], 
...)`, and later I can use `store i8* [[HANDLE]], i8** [[HANDLEADDR:%[^,]+]]`

I'm not sure how to add names for function arguments. They seems to be always 
nameless like `(i8*, i8*, i8*, i64, i64)`. Is there a way to do that?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 212399.
lildmh marked an inline comment as done.
lildmh added a comment.

Change mapper function argument checking


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %cl

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Hi David,

An extra bit is needed to be added to `IdentifierNamespace`, and I could not 
find another field to shrink its width. As a result, it ends up larger than a 
word now. If you have a better solution, I'll be happy to know.

Thanks,
Lingda


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56326/new/

https://reviews.llvm.org/D56326



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 213339.
lildmh added a comment.

Fix declare mapper codegen test when the function argument has name attached.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > Currently `currentComponent` is generated by the compiler. But can we 
> > > > > instead pass this data as an extra parameter to this `omp_mapper` 
> > > > > function.
> > > > Emm, I think this scheme will be very difficult and inefficient. If we 
> > > > pass components as an argument of `omp_mapper` function, it means that 
> > > > the runtime needs to generate all components related to a map clause. I 
> > > > don't think the runtime is able to do that efficiently. On the other 
> > > > hand, in the current scheme, these components are naturally generated 
> > > > by the compiler, and the runtime only needs to know the base pointer, 
> > > > pointer, type, size. etc.
> > > With the current scheme, we may end with the code blowout. We need to 
> > > generate very similar code for different types and variables. The worst 
> > > thing here is that we will be unable to optimize this huge amount of code 
> > > because the codegen relies on the runtime functions and the code cannot 
> > > be inlined. That's why I would like to move as much as possible code to 
> > > the runtime rather than to emit it in the compiler. 
> > I understand your concerns. I think this is the best we can do right now.
> > 
> > The most worrisome case will be when we have nested mappers within each 
> > other. In this case, a mapper function will call another mapper function. 
> > We can inline the inner mapper functions in this scenario, so that these 
> > mapper function can be properly optimized. As a result, I think the 
> > performance should be fine.
> Instead, we can use indirect function calls passed in the array to the 
> runtime. Do you think it is going to be slower? In your current scheme, we 
> generate many runtime calls instead. Could you try to estimate the number of 
> calls in cases if we'll call the mappers through the indirect function calls 
> and in your cuurent scheme, where we need to call the runtime functions many 
> times in each particular mapper?
Hi Alexey,

Sorry I don't understand your idea. What indirect function calls do you propose 
to be passed to the runtime? What are these functions supposed to do?

The number of function calls will be exactly equal to the number of components 
mapped, no matter whether there are nested mappers or not. The number of 
components depend on the program. E.g., if we map a large array section, then 
there will be many more function calls.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 4 inline comments as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > Currently `currentComponent` is generated by the compiler. But 
> > > > > > > can we instead pass this data as an extra parameter to this 
> > > > > > > `omp_mapper` function.
> > > > > > Emm, I think this scheme will be very difficult and inefficient. If 
> > > > > > we pass components as an argument of `omp_mapper` function, it 
> > > > > > means that the runtime needs to generate all components related to 
> > > > > > a map clause. I don't think the runtime is able to do that 
> > > > > > efficiently. On the other hand, in the current scheme, these 
> > > > > > components are naturally generated by the compiler, and the runtime 
> > > > > > only needs to know the base pointer, pointer, type, size. etc.
> > > > > With the current scheme, we may end with the code blowout. We need to 
> > > > > generate very similar code for different types and variables. The 
> > > > > worst thing here is that we will be unable to optimize this huge 
> > > > > amount of code because the codegen relies on the runtime functions 
> > > > > and the code cannot be inlined. That's why I would like to move as 
> > > > > much as possible code to the runtime rather than to emit it in the 
> > > > > compiler. 
> > > > I understand your concerns. I think this is the best we can do right 
> > > > now.
> > > > 
> > > > The most worrisome case will be when we have nested mappers within each 
> > > > other. In this case, a mapper function will call another mapper 
> > > > function. We can inline the inner mapper functions in this scenario, so 
> > > > that these mapper function can be properly optimized. As a result, I 
> > > > think the performance should be fine.
> > > Instead, we can use indirect function calls passed in the array to the 
> > > runtime. Do you think it is going to be slower? In your current scheme, 
> > > we generate many runtime calls instead. Could you try to estimate the 
> > > number of calls in cases if we'll call the mappers through the indirect 
> > > function calls and in your cuurent scheme, where we need to call the 
> > > runtime functions many times in each particular mapper?
> > Hi Alexey,
> > 
> > Sorry I don't understand your idea. What indirect function calls do you 
> > propose to be passed to the runtime? What are these functions supposed to 
> > do?
> > 
> > The number of function calls will be exactly equal to the number of 
> > components mapped, no matter whether there are nested mappers or not. The 
> > number of components depend on the program. E.g., if we map a large array 
> > section, then there will be many more function calls.
> I mean the pointers to the mapper function, generated by the compiler. In 
> your comment, it is `c.Mapper()`
If we pass nested mapper functions to the runtime, I think it will slow down 
execution because of the extra level of indirect function calls. E.g., the 
runtime will call `omp_mapper1`, which calls the runtime back, which calls 
`omp_mapper2`,  This can result in a deep call stack.

I think the current implementation will be more efficient, which doesn't pass 
nested mappers to the runtime. One call to the outer most mapper function will 
have all data mapping done. The call stack will be 2 level deep (the first 
level is the mapper function, and the second level is 
`__tgt_push_mapper_component`) in this case from the runtime. There are also 
more compiler optimization space when we inline all nested mapper functions.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 2 inline comments as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:744
   OMPRTL__tgt_target_data_update_nowait,
+  // Call to int64_t __tgt_mapper_num_components(void *rt_mapper_handle);
+  OMPRTL__tgt_mapper_num_components,

ABataev wrote:
> Do we really need to use `int64_t` for number of elements? `size_t` must be 
> enough.
Because we use the return value to shift the memberof filed of map type, which 
is `int64_t`, so I think `int64_t` makes sense here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 206527.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-un

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > Currently `currentComponent` is generated by the compiler. 
> > > > > > > > > But can we instead pass this data as an extra parameter to 
> > > > > > > > > this `omp_mapper` function.
> > > > > > > > Emm, I think this scheme will be very difficult and 
> > > > > > > > inefficient. If we pass components as an argument of 
> > > > > > > > `omp_mapper` function, it means that the runtime needs to 
> > > > > > > > generate all components related to a map clause. I don't think 
> > > > > > > > the runtime is able to do that efficiently. On the other hand, 
> > > > > > > > in the current scheme, these components are naturally generated 
> > > > > > > > by the compiler, and the runtime only needs to know the base 
> > > > > > > > pointer, pointer, type, size. etc.
> > > > > > > With the current scheme, we may end with the code blowout. We 
> > > > > > > need to generate very similar code for different types and 
> > > > > > > variables. The worst thing here is that we will be unable to 
> > > > > > > optimize this huge amount of code because the codegen relies on 
> > > > > > > the runtime functions and the code cannot be inlined. That's why 
> > > > > > > I would like to move as much as possible code to the runtime 
> > > > > > > rather than to emit it in the compiler. 
> > > > > > I understand your concerns. I think this is the best we can do 
> > > > > > right now.
> > > > > > 
> > > > > > The most worrisome case will be when we have nested mappers within 
> > > > > > each other. In this case, a mapper function will call another 
> > > > > > mapper function. We can inline the inner mapper functions in this 
> > > > > > scenario, so that these mapper function can be properly optimized. 
> > > > > > As a result, I think the performance should be fine.
> > > > > Instead, we can use indirect function calls passed in the array to 
> > > > > the runtime. Do you think it is going to be slower? In your current 
> > > > > scheme, we generate many runtime calls instead. Could you try to 
> > > > > estimate the number of calls in cases if we'll call the mappers 
> > > > > through the indirect function calls and in your cuurent scheme, where 
> > > > > we need to call the runtime functions many times in each particular 
> > > > > mapper?
> > > > Hi Alexey,
> > > > 
> > > > Sorry I don't understand your idea. What indirect function calls do you 
> > > > propose to be passed to the runtime? What are these functions supposed 
> > > > to do?
> > > > 
> > > > The number of function calls will be exactly equal to the number of 
> > > > components mapped, no matter whether there are nested mappers or not. 
> > > > The number of components depend on the program. E.g., if we map a large 
> > > > array section, then there will be many more function calls.
> > > I mean the pointers to the mapper function, generated by the compiler. In 
> > > your comment, it is `c.Mapper()`
> > If we pass nested mapper functions to the runtime, I think it will slow 
> > down execution because of the extra level of indirect function calls. E.g., 
> > the runtime will call `omp_mapper1`, which calls the runtime back, which 
> > calls `omp_mapper2`,  This can result in a deep call stack.
> > 
> > I think the current implementation will be more efficient, which doesn't 
> > pass nested mappers to the runtime. One call to the outer most mapper 
> > function will have all data mapping done. The call stack will be 2 level 
> > deep (the first level is the mapper function, and the second level is 
> > `__tgt_push_mapper_component`) in this case from the runtime. There are 
> > also more compiler optimization space when we inline all nested mapper 
> > functions.
> Yes, if we leave it as is. But if instead of the bunch unique functions we'll 
> have the common one, that accept list if indirect pointers to functions 
> additionally, and move it to the runtime library, we won't need those 2 
> functions we have currently. We'll have full access to the mapping data 
> vector in the runtime library and won't need to use those 2 accessors we have 
> currently. Instead, we'll need just one runtime functions, which implements 
> the whole mapping logic. We still need to call it recursively, but I assume 
> the number of calls will remain the same as in the current scheme. Did you 
> understand the idea? If yes, it would good if you coild try to estimate the 
> number of function calls in current scheme and in this n

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:744
   OMPRTL__tgt_target_data_update_nowait,
+  // Call to int64_t __tgt_mapper_num_components(void *rt_mapper_handle);
+  OMPRTL__tgt_mapper_num_components,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Do we really need to use `int64_t` for number of elements? `size_t` must 
> > > be enough.
> > Because we use the return value to shift the memberof filed of map type, 
> > which is `int64_t`, so I think `int64_t` makes sense here.
> Ok, there is a discrepancy between runtime part and compiler part: 
> `__tgt_push_mapper_component` uses `size_t` for size, while the runtime 
> function uses `int64_t`. It won't work for 32bit platform.
This should work on 32bit machines, since 32bit machines also use `int64_t` for 
the map type?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 2 inline comments as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > Currently `currentComponent` is generated by the 
> > > > > > > > > > > compiler. But can we instead pass this data as an extra 
> > > > > > > > > > > parameter to this `omp_mapper` function.
> > > > > > > > > > Emm, I think this scheme will be very difficult and 
> > > > > > > > > > inefficient. If we pass components as an argument of 
> > > > > > > > > > `omp_mapper` function, it means that the runtime needs to 
> > > > > > > > > > generate all components related to a map clause. I don't 
> > > > > > > > > > think the runtime is able to do that efficiently. On the 
> > > > > > > > > > other hand, in the current scheme, these components are 
> > > > > > > > > > naturally generated by the compiler, and the runtime only 
> > > > > > > > > > needs to know the base pointer, pointer, type, size. etc.
> > > > > > > > > With the current scheme, we may end with the code blowout. We 
> > > > > > > > > need to generate very similar code for different types and 
> > > > > > > > > variables. The worst thing here is that we will be unable to 
> > > > > > > > > optimize this huge amount of code because the codegen relies 
> > > > > > > > > on the runtime functions and the code cannot be inlined. 
> > > > > > > > > That's why I would like to move as much as possible code to 
> > > > > > > > > the runtime rather than to emit it in the compiler. 
> > > > > > > > I understand your concerns. I think this is the best we can do 
> > > > > > > > right now.
> > > > > > > > 
> > > > > > > > The most worrisome case will be when we have nested mappers 
> > > > > > > > within each other. In this case, a mapper function will call 
> > > > > > > > another mapper function. We can inline the inner mapper 
> > > > > > > > functions in this scenario, so that these mapper function can 
> > > > > > > > be properly optimized. As a result, I think the performance 
> > > > > > > > should be fine.
> > > > > > > Instead, we can use indirect function calls passed in the array 
> > > > > > > to the runtime. Do you think it is going to be slower? In your 
> > > > > > > current scheme, we generate many runtime calls instead. Could you 
> > > > > > > try to estimate the number of calls in cases if we'll call the 
> > > > > > > mappers through the indirect function calls and in your cuurent 
> > > > > > > scheme, where we need to call the runtime functions many times in 
> > > > > > > each particular mapper?
> > > > > > Hi Alexey,
> > > > > > 
> > > > > > Sorry I don't understand your idea. What indirect function calls do 
> > > > > > you propose to be passed to the runtime? What are these functions 
> > > > > > supposed to do?
> > > > > > 
> > > > > > The number of function calls will be exactly equal to the number of 
> > > > > > components mapped, no matter whether there are nested mappers or 
> > > > > > not. The number of components depend on the program. E.g., if we 
> > > > > > map a large array section, then there will be many more function 
> > > > > > calls.
> > > > > I mean the pointers to the mapper function, generated by the 
> > > > > compiler. In your comment, it is `c.Mapper()`
> > > > If we pass nested mapper functions to the runtime, I think it will slow 
> > > > down execution because of the extra level of indirect function calls. 
> > > > E.g., the runtime will call `omp_mapper1`, which calls the runtime 
> > > > back, which calls `omp_mapper2`,  This can result in a deep call 
> > > > stack.
> > > > 
> > > > I think the current implementation will be more efficient, which 
> > > > doesn't pass nested mappers to the runtime. One call to the outer most 
> > > > mapper function will have all data mapping done. The call stack will be 
> > > > 2 level deep (the first level is the mapper function, and the second 
> > > > level is `__tgt_push_mapper_component`) in this case from the runtime. 
> > > > There are also more compiler optimization space when we inline all 
> > > > nested mapper functions.
> > > Yes, if we leave it as is. But if instead of the bunch unique functions 
> > > we'll have the common one, that accept list if indirect pointers to 
> > > functions additionally, and move it to the runtime library, we won't need 
> > > those 2 functions we have currently. We'll have full access to the 
> > > mapping data vector in the runtime library and won't need to use those 2 
> > > accessors we have currently. In

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked 2 inline comments as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > Currently `currentComponent` is generated by the 
> > > > > > > > > > > > > compiler. But can we instead pass this data as an 
> > > > > > > > > > > > > extra parameter to this `omp_mapper` function.
> > > > > > > > > > > > Emm, I think this scheme will be very difficult and 
> > > > > > > > > > > > inefficient. If we pass components as an argument of 
> > > > > > > > > > > > `omp_mapper` function, it means that the runtime needs 
> > > > > > > > > > > > to generate all components related to a map clause. I 
> > > > > > > > > > > > don't think the runtime is able to do that efficiently. 
> > > > > > > > > > > > On the other hand, in the current scheme, these 
> > > > > > > > > > > > components are naturally generated by the compiler, and 
> > > > > > > > > > > > the runtime only needs to know the base pointer, 
> > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > With the current scheme, we may end with the code 
> > > > > > > > > > > blowout. We need to generate very similar code for 
> > > > > > > > > > > different types and variables. The worst thing here is 
> > > > > > > > > > > that we will be unable to optimize this huge amount of 
> > > > > > > > > > > code because the codegen relies on the runtime functions 
> > > > > > > > > > > and the code cannot be inlined. That's why I would like 
> > > > > > > > > > > to move as much as possible code to the runtime rather 
> > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > I understand your concerns. I think this is the best we can 
> > > > > > > > > > do right now.
> > > > > > > > > > 
> > > > > > > > > > The most worrisome case will be when we have nested mappers 
> > > > > > > > > > within each other. In this case, a mapper function will 
> > > > > > > > > > call another mapper function. We can inline the inner 
> > > > > > > > > > mapper functions in this scenario, so that these mapper 
> > > > > > > > > > function can be properly optimized. As a result, I think 
> > > > > > > > > > the performance should be fine.
> > > > > > > > > Instead, we can use indirect function calls passed in the 
> > > > > > > > > array to the runtime. Do you think it is going to be slower? 
> > > > > > > > > In your current scheme, we generate many runtime calls 
> > > > > > > > > instead. Could you try to estimate the number of calls in 
> > > > > > > > > cases if we'll call the mappers through the indirect function 
> > > > > > > > > calls and in your cuurent scheme, where we need to call the 
> > > > > > > > > runtime functions many times in each particular mapper?
> > > > > > > > Hi Alexey,
> > > > > > > > 
> > > > > > > > Sorry I don't understand your idea. What indirect function 
> > > > > > > > calls do you propose to be passed to the runtime? What are 
> > > > > > > > these functions supposed to do?
> > > > > > > > 
> > > > > > > > The number of function calls will be exactly equal to the 
> > > > > > > > number of components mapped, no matter whether there are nested 
> > > > > > > > mappers or not. The number of components depend on the program. 
> > > > > > > > E.g., if we map a large array section, then there will be many 
> > > > > > > > more function calls.
> > > > > > > I mean the pointers to the mapper function, generated by the 
> > > > > > > compiler. In your comment, it is `c.Mapper()`
> > > > > > If we pass nested mapper functions to the runtime, I think it will 
> > > > > > slow down execution because of the extra level of indirect function 
> > > > > > calls. E.g., the runtime will call `omp_mapper1`, which calls the 
> > > > > > runtime back, which calls `omp_mapper2`,  This can result in a 
> > > > > > deep call stack.
> > > > > > 
> > > > > > I think the current implementation will be more efficient, which 
> > > > > > doesn't pass nested mappers to the runtime. One call to the outer 
> > > > > > most mapper function will have all data mapping done. The call 
> > > > > > stack will be 2 level deep (the first level is the mapper function, 
> > > > > > and the second level is `__tgt_push_mapper_component`) in this case 
> > > > > > from the runtime. There are also more compiler optimization space 
> > > > > > when we inline all nested mapper functions.
> > > > > Yes, if we leave it as is. But if instead of the bunc

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > Currently `currentComponent` is generated by the 
> > > > > > > > > > > > > > > compiler. But can we instead pass this data as an 
> > > > > > > > > > > > > > > extra parameter to this `omp_mapper` function.
> > > > > > > > > > > > > > Emm, I think this scheme will be very difficult and 
> > > > > > > > > > > > > > inefficient. If we pass components as an argument 
> > > > > > > > > > > > > > of `omp_mapper` function, it means that the runtime 
> > > > > > > > > > > > > > needs to generate all components related to a map 
> > > > > > > > > > > > > > clause. I don't think the runtime is able to do 
> > > > > > > > > > > > > > that efficiently. On the other hand, in the current 
> > > > > > > > > > > > > > scheme, these components are naturally generated by 
> > > > > > > > > > > > > > the compiler, and the runtime only needs to know 
> > > > > > > > > > > > > > the base pointer, pointer, type, size. etc.
> > > > > > > > > > > > > With the current scheme, we may end with the code 
> > > > > > > > > > > > > blowout. We need to generate very similar code for 
> > > > > > > > > > > > > different types and variables. The worst thing here 
> > > > > > > > > > > > > is that we will be unable to optimize this huge 
> > > > > > > > > > > > > amount of code because the codegen relies on the 
> > > > > > > > > > > > > runtime functions and the code cannot be inlined. 
> > > > > > > > > > > > > That's why I would like to move as much as possible 
> > > > > > > > > > > > > code to the runtime rather than to emit it in the 
> > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > I understand your concerns. I think this is the best we 
> > > > > > > > > > > > can do right now.
> > > > > > > > > > > > 
> > > > > > > > > > > > The most worrisome case will be when we have nested 
> > > > > > > > > > > > mappers within each other. In this case, a mapper 
> > > > > > > > > > > > function will call another mapper function. We can 
> > > > > > > > > > > > inline the inner mapper functions in this scenario, so 
> > > > > > > > > > > > that these mapper function can be properly optimized. 
> > > > > > > > > > > > As a result, I think the performance should be fine.
> > > > > > > > > > > Instead, we can use indirect function calls passed in the 
> > > > > > > > > > > array to the runtime. Do you think it is going to be 
> > > > > > > > > > > slower? In your current scheme, we generate many runtime 
> > > > > > > > > > > calls instead. Could you try to estimate the number of 
> > > > > > > > > > > calls in cases if we'll call the mappers through the 
> > > > > > > > > > > indirect function calls and in your cuurent scheme, where 
> > > > > > > > > > > we need to call the runtime functions many times in each 
> > > > > > > > > > > particular mapper?
> > > > > > > > > > Hi Alexey,
> > > > > > > > > > 
> > > > > > > > > > Sorry I don't understand your idea. What indirect function 
> > > > > > > > > > calls do you propose to be passed to the runtime? What are 
> > > > > > > > > > these functions supposed to do?
> > > > > > > > > > 
> > > > > > > > > > The number of function calls will be exactly equal to the 
> > > > > > > > > > number of components mapped, no matter whether there are 
> > > > > > > > > > nested mappers or not. The number of components depend on 
> > > > > > > > > > the program. E.g., if we map a large array section, then 
> > > > > > > > > > there will be many more function calls.
> > > > > > > > > I mean the pointers to the mapper function, generated by the 
> > > > > > > > > compiler. In your comment, it is `c.Mapper()`
> > > > > > > > If we pass nested mapper functions to the runtime, I think it 
> > > > > > > > will slow down execution because of the extra level of indirect 
> > > > > > > > function calls. E.g., the runtime will call `omp_mapper1`, 
> > > > > > > > which calls the runtime back, which calls `omp_mapper2`,  
> > > > > > > > This can result in a deep call stack.
> > > > > > > > 
> > > > > > > > I think the current implementation will be more efficient, 
> > > > > > > > which doesn't pass nested mappers to the runtime. One call to 
> > > > > > > > the outer most mapper function will have all data mapping done. 
> > 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > Currently `currentComponent` is generated by 
> > > > > > > > > > > > > > > > > the compiler. But can we instead pass this 
> > > > > > > > > > > > > > > > > data as an extra parameter to this 
> > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > Emm, I think this scheme will be very difficult 
> > > > > > > > > > > > > > > > and inefficient. If we pass components as an 
> > > > > > > > > > > > > > > > argument of `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > that the runtime needs to generate all 
> > > > > > > > > > > > > > > > components related to a map clause. I don't 
> > > > > > > > > > > > > > > > think the runtime is able to do that 
> > > > > > > > > > > > > > > > efficiently. On the other hand, in the current 
> > > > > > > > > > > > > > > > scheme, these components are naturally 
> > > > > > > > > > > > > > > > generated by the compiler, and the runtime only 
> > > > > > > > > > > > > > > > needs to know the base pointer, pointer, type, 
> > > > > > > > > > > > > > > > size. etc.
> > > > > > > > > > > > > > > With the current scheme, we may end with the code 
> > > > > > > > > > > > > > > blowout. We need to generate very similar code 
> > > > > > > > > > > > > > > for different types and variables. The worst 
> > > > > > > > > > > > > > > thing here is that we will be unable to optimize 
> > > > > > > > > > > > > > > this huge amount of code because the codegen 
> > > > > > > > > > > > > > > relies on the runtime functions and the code 
> > > > > > > > > > > > > > > cannot be inlined. That's why I would like to 
> > > > > > > > > > > > > > > move as much as possible code to the runtime 
> > > > > > > > > > > > > > > rather than to emit it in the compiler. 
> > > > > > > > > > > > > > I understand your concerns. I think this is the 
> > > > > > > > > > > > > > best we can do right now.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The most worrisome case will be when we have nested 
> > > > > > > > > > > > > > mappers within each other. In this case, a mapper 
> > > > > > > > > > > > > > function will call another mapper function. We can 
> > > > > > > > > > > > > > inline the inner mapper functions in this scenario, 
> > > > > > > > > > > > > > so that these mapper function can be properly 
> > > > > > > > > > > > > > optimized. As a result, I think the performance 
> > > > > > > > > > > > > > should be fine.
> > > > > > > > > > > > > Instead, we can use indirect function calls passed in 
> > > > > > > > > > > > > the array to the runtime. Do you think it is going to 
> > > > > > > > > > > > > be slower? In your current scheme, we generate many 
> > > > > > > > > > > > > runtime calls instead. Could you try to estimate the 
> > > > > > > > > > > > > number of calls in cases if we'll call the mappers 
> > > > > > > > > > > > > through the indirect function calls and in your 
> > > > > > > > > > > > > cuurent scheme, where we need to call the runtime 
> > > > > > > > > > > > > functions many times in each particular mapper?
> > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > 
> > > > > > > > > > > > Sorry I don't understand your idea. What indirect 
> > > > > > > > > > > > function calls do you propose to be passed to the 
> > > > > > > > > > > > runtime? What are these functions supposed to do?
> > > > > > > > > > > > 
> > > > > > > > > > > > The number of function calls will be exactly equal to 
> > > > > > > > > > > > the number of components mapped, no matter whether 
> > > > > > > > > > > > there are nested mappers or not. The number of 
> > > > > > > > > > > > components depend on the program. E.g., if we map a 
> > > > > > > > > > > > large array section, then there will be many more 
> > > > > > > > > > > > function calls.
> > > > > > > > > > > I mean the pointers to the mapper function, generated by 
> > > > > > > > > > > the compiler. In your comment, it is `c.Mapper()`
> > > > > > > > > > If we pass nested mapper functions to the runtime, I think 
> > > > > > > > > > it will slow down execution because of the extra level of 
> > > > > > > > >

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > Currently `currentComponent` is generated 
> > > > > > > > > > > > > > > > > > > by the compiler. But can we instead pass 
> > > > > > > > > > > > > > > > > > > this data as an extra parameter to this 
> > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > components as an argument of `omp_mapper` 
> > > > > > > > > > > > > > > > > > function, it means that the runtime needs 
> > > > > > > > > > > > > > > > > > to generate all components related to a map 
> > > > > > > > > > > > > > > > > > clause. I don't think the runtime is able 
> > > > > > > > > > > > > > > > > > to do that efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > in the current scheme, these components are 
> > > > > > > > > > > > > > > > > > naturally generated by the compiler, and 
> > > > > > > > > > > > > > > > > > the runtime only needs to know the base 
> > > > > > > > > > > > > > > > > > pointer, pointer, type, size. etc.
> > > > > > > > > > > > > > > > > With the current scheme, we may end with the 
> > > > > > > > > > > > > > > > > code blowout. We need to generate very 
> > > > > > > > > > > > > > > > > similar code for different types and 
> > > > > > > > > > > > > > > > > variables. The worst thing here is that we 
> > > > > > > > > > > > > > > > > will be unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > of code because the codegen relies on the 
> > > > > > > > > > > > > > > > > runtime functions and the code cannot be 
> > > > > > > > > > > > > > > > > inlined. That's why I would like to move as 
> > > > > > > > > > > > > > > > > much as possible code to the runtime rather 
> > > > > > > > > > > > > > > > > than to emit it in the compiler. 
> > > > > > > > > > > > > > > > I understand your concerns. I think this is the 
> > > > > > > > > > > > > > > > best we can do right now.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > The most worrisome case will be when we have 
> > > > > > > > > > > > > > > > nested mappers within each other. In this case, 
> > > > > > > > > > > > > > > > a mapper function will call another mapper 
> > > > > > > > > > > > > > > > function. We can inline the inner mapper 
> > > > > > > > > > > > > > > > functions in this scenario, so that these 
> > > > > > > > > > > > > > > > mapper function can be properly optimized. As a 
> > > > > > > > > > > > > > > > result, I think the performance should be fine.
> > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > passed in the array to the runtime. Do you think 
> > > > > > > > > > > > > > > it is going to be slower? In your current scheme, 
> > > > > > > > > > > > > > > we generate many runtime calls instead. Could you 
> > > > > > > > > > > > > > > try to estimate the number of calls in cases if 
> > > > > > > > > > > > > > > we'll call the mappers through the indirect 
> > > > > > > > > > > > > > > function calls and in your cuurent scheme, where 
> > > > > > > > > > > > > > > we need to call the runtime functions many times 
> > > > > > > > > > > > > > > in each particular mapper?
> > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Sorry I don't understand your idea. What indirect 
> > > > > > > > > > > > > > function calls do you propose to be passed to the 
> > > > > > > > > > > > > > runtime? What are these functions supposed to do?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The number of function calls will be exactly equal 
> > > > > > > > > > > > > > to the number of components mapped, no matter 
> > > > > > > > > > > > > > whether there are nested mappers or not. The number 
> > > > > > > > > > > > > > of components depend on the program. E.g., if we 
> > > > > > > > > > > > > > map a large array section, then there will be ma

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > generated by the compiler. But can we 
> > > > > > > > > > > > > > > > > > > > > instead pass this data as an extra 
> > > > > > > > > > > > > > > > > > > > > parameter to this `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > function.
> > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be very 
> > > > > > > > > > > > > > > > > > > > difficult and inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means that 
> > > > > > > > > > > > > > > > > > > > the runtime needs to generate all 
> > > > > > > > > > > > > > > > > > > > components related to a map clause. I 
> > > > > > > > > > > > > > > > > > > > don't think the runtime is able to do 
> > > > > > > > > > > > > > > > > > > > that efficiently. On the other hand, in 
> > > > > > > > > > > > > > > > > > > > the current scheme, these components 
> > > > > > > > > > > > > > > > > > > > are naturally generated by the 
> > > > > > > > > > > > > > > > > > > > compiler, and the runtime only needs to 
> > > > > > > > > > > > > > > > > > > > know the base pointer, pointer, type, 
> > > > > > > > > > > > > > > > > > > > size. etc.
> > > > > > > > > > > > > > > > > > > With the current scheme, we may end with 
> > > > > > > > > > > > > > > > > > > the code blowout. We need to generate 
> > > > > > > > > > > > > > > > > > > very similar code for different types and 
> > > > > > > > > > > > > > > > > > > variables. The worst thing here is that 
> > > > > > > > > > > > > > > > > > > we will be unable to optimize this huge 
> > > > > > > > > > > > > > > > > > > amount of code because the codegen relies 
> > > > > > > > > > > > > > > > > > > on the runtime functions and the code 
> > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I would 
> > > > > > > > > > > > > > > > > > > like to move as much as possible code to 
> > > > > > > > > > > > > > > > > > > the runtime rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > I understand your concerns. I think this is 
> > > > > > > > > > > > > > > > > > the best we can do right now.
> > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > have nested mappers within each other. In 
> > > > > > > > > > > > > > > > > > this case, a mapper function will call 
> > > > > > > > > > > > > > > > > > another mapper function. We can inline the 
> > > > > > > > > > > > > > > > > > inner mapper functions in this scenario, so 
> > > > > > > > > > > > > > > > > > that these mapper function can be properly 
> > > > > > > > > > > > > > > > > > optimized. As a result, I think the 
> > > > > > > > > > > > > > > > > > performance should be fine.
> > > > > > > > > > > > > > > > > Instead, we can use indirect function calls 
> > > > > > > > > > > > > > > > > passed in the array to the runtime. Do you 
> > > > > > > > > > > > > > > > > think it is going to be slower? In your 
> > > > > > > > > > > > > > > > > current scheme, we generate many runtime 
> > > > > > > > > > > > > > > > > calls instead. Could you try to estimate the 
> > > > > > > > > > > > > > > > > number of calls in cases if we'll call the 
> > > > > > > > > > > > > > > > > mappers through the indirect function calls 
> > > > > > > > > > > > > > > > > and in your cuurent scheme, where we need to 
> > > > > > > > > > > > > > > > > call the runtime functions many times in each 
> > > > > > > > > > > > > > > > > particular mapper?
> > > > > > > > > > > > > > > > Hi Alexey,
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > Sorry I don't understand your idea. What 
> > > > > > > > > > > > > > > > indirect function call

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > generated by the compiler. But 
> > > > > > > > > > > > > > > > > > > > > > > can we instead pass this data as 
> > > > > > > > > > > > > > > > > > > > > > > an extra parameter to this 
> > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will be 
> > > > > > > > > > > > > > > > > > > > > > very difficult and inefficient. If 
> > > > > > > > > > > > > > > > > > > > > > we pass components as an argument 
> > > > > > > > > > > > > > > > > > > > > > of `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > > > > > > > that the runtime needs to generate 
> > > > > > > > > > > > > > > > > > > > > > all components related to a map 
> > > > > > > > > > > > > > > > > > > > > > clause. I don't think the runtime 
> > > > > > > > > > > > > > > > > > > > > > is able to do that efficiently. On 
> > > > > > > > > > > > > > > > > > > > > > the other hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > scheme, these components are 
> > > > > > > > > > > > > > > > > > > > > > naturally generated by the 
> > > > > > > > > > > > > > > > > > > > > > compiler, and the runtime only 
> > > > > > > > > > > > > > > > > > > > > > needs to know the base pointer, 
> > > > > > > > > > > > > > > > > > > > > > pointer, type, size. etc.
> > > > > > > > > > > > > > > > > > > > > With the current scheme, we may end 
> > > > > > > > > > > > > > > > > > > > > with the code blowout. We need to 
> > > > > > > > > > > > > > > > > > > > > generate very similar code for 
> > > > > > > > > > > > > > > > > > > > > different types and variables. The 
> > > > > > > > > > > > > > > > > > > > > worst thing here is that we will be 
> > > > > > > > > > > > > > > > > > > > > unable to optimize this huge amount 
> > > > > > > > > > > > > > > > > > > > > of code because the codegen relies on 
> > > > > > > > > > > > > > > > > > > > > the runtime functions and the code 
> > > > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I would 
> > > > > > > > > > > > > > > > > > > > > like to move as much as possible code 
> > > > > > > > > > > > > > > > > > > > > to the runtime rather than to emit it 
> > > > > > > > > > > > > > > > > > > > > in the compiler. 
> > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > this is the best we can do right now.
> > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > The most worrisome case will be when we 
> > > > > > > > > > > > > > > > > > > > have nested mappers within each other. 
> > > > > > > > > > > > > > > > > > > > In this case, a mapper function will 
> > > > > > > > > > > > > > > > > > > > call another mapper function. We can 
> > > > > > > > > > > > > > > > > > > > inline the inner mapper functions in 
> > > > > > > > > > > > > > > > > > > > this scenario, so that these mapper 
> > > > > > > > > > > > > > > > > > > > function can be properly optimized. As 
> > > > > > > > > > > > > > > > > > > > a result, I think the performance 
> > > > > > > > > > > > > > > > > > > > should be fine.
> > > > > > > > > > > > > > > > > > > Instead, we can use indirect function 
> > > > > > > > > > > > > > > > > > > calls passed in the array to the runtime. 
> > > > > > > > > > > > > > > > > > > Do you think it is going to be slower? In 
> > > > > > > > > > > > > > > > > > > your current scheme, we generate many 
> > > > > > > > > > > > > > > > > > > runtime calls instead. Could you try to 
> > > > > > > > > > > > > > > > > > > estimate the number of calls in cases if 
> > > > > > > > > > > > > > > > > > > we'll call the mappers through the 
> > > > > 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > Currently `currentComponent` 
> > > > > > > > > > > > > > > > > > > > > > > > > is generated by the compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > > But can we instead pass this 
> > > > > > > > > > > > > > > > > > > > > > > > > data as an extra parameter to 
> > > > > > > > > > > > > > > > > > > > > > > > > this `omp_mapper` function.
> > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme will 
> > > > > > > > > > > > > > > > > > > > > > > > be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > components as an argument of 
> > > > > > > > > > > > > > > > > > > > > > > > `omp_mapper` function, it means 
> > > > > > > > > > > > > > > > > > > > > > > > that the runtime needs to 
> > > > > > > > > > > > > > > > > > > > > > > > generate all components related 
> > > > > > > > > > > > > > > > > > > > > > > > to a map clause. I don't think 
> > > > > > > > > > > > > > > > > > > > > > > > the runtime is able to do that 
> > > > > > > > > > > > > > > > > > > > > > > > efficiently. On the other hand, 
> > > > > > > > > > > > > > > > > > > > > > > > in the current scheme, these 
> > > > > > > > > > > > > > > > > > > > > > > > components are naturally 
> > > > > > > > > > > > > > > > > > > > > > > > generated by the compiler, and 
> > > > > > > > > > > > > > > > > > > > > > > > the runtime only needs to know 
> > > > > > > > > > > > > > > > > > > > > > > > the base pointer, pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we may 
> > > > > > > > > > > > > > > > > > > > > > > end with the code blowout. We 
> > > > > > > > > > > > > > > > > > > > > > > need to generate very similar 
> > > > > > > > > > > > > > > > > > > > > > > code for different types and 
> > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing here 
> > > > > > > > > > > > > > > > > > > > > > > is that we will be unable to 
> > > > > > > > > > > > > > > > > > > > > > > optimize this huge amount of code 
> > > > > > > > > > > > > > > > > > > > > > > because the codegen relies on the 
> > > > > > > > > > > > > > > > > > > > > > > runtime functions and the code 
> > > > > > > > > > > > > > > > > > > > > > > cannot be inlined. That's why I 
> > > > > > > > > > > > > > > > > > > > > > > would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > > possible code to the runtime 
> > > > > > > > > > > > > > > > > > > > > > > rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I think 
> > > > > > > > > > > > > > > > > > > > > > this is the best we can do right 
> > > > > > > > > > > > > > > > > > > > > > now.
> > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > > > > > > > > > > > > > > > > > > > > > when we have nested mappers within 
> > > > > > > > > > > > > > > > > > > > > > each other. In this case, a mapper 
> > > > > > > > > > > > > > > > > > > > > > function will call another mapper 
> > > > > > > > > > > > > > > > > > > > > > function. We can inline the inner 
> > > > > > > > > > > > > > > > > > > > > > mapper functions in this scenario, 
> > > > > > > > > > > > > > > > > > > > > > so that these mapper function can 
> > > > > > > > > > > > > > > > > > > > > > be properly optimized. As a result, 
> > > > > > > > > > > > > > > > > > > > > > I think the performance should be 
> > > > > > > > > > > > > > > > 

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8739
+/// // For each component specified by this mapper:
+/// if (currentComponent.hasMapper())
+///   (*currentComponent.Mapper())(rt_mapper_handle, arg_base, arg_begin,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > lildmh wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > lildmh wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > lildmh wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > Currently 
> > > > > > > > > > > > > > > > > > > > > > > > > > > `currentComponent` is 
> > > > > > > > > > > > > > > > > > > > > > > > > > > generated by the 
> > > > > > > > > > > > > > > > > > > > > > > > > > > compiler. But can we 
> > > > > > > > > > > > > > > > > > > > > > > > > > > instead pass this data as 
> > > > > > > > > > > > > > > > > > > > > > > > > > > an extra parameter to 
> > > > > > > > > > > > > > > > > > > > > > > > > > > this `omp_mapper` 
> > > > > > > > > > > > > > > > > > > > > > > > > > > function.
> > > > > > > > > > > > > > > > > > > > > > > > > > Emm, I think this scheme 
> > > > > > > > > > > > > > > > > > > > > > > > > > will be very difficult and 
> > > > > > > > > > > > > > > > > > > > > > > > > > inefficient. If we pass 
> > > > > > > > > > > > > > > > > > > > > > > > > > components as an argument 
> > > > > > > > > > > > > > > > > > > > > > > > > > of `omp_mapper` function, 
> > > > > > > > > > > > > > > > > > > > > > > > > > it means that the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > > needs to generate all 
> > > > > > > > > > > > > > > > > > > > > > > > > > components related to a map 
> > > > > > > > > > > > > > > > > > > > > > > > > > clause. I don't think the 
> > > > > > > > > > > > > > > > > > > > > > > > > > runtime is able to do that 
> > > > > > > > > > > > > > > > > > > > > > > > > > efficiently. On the other 
> > > > > > > > > > > > > > > > > > > > > > > > > > hand, in the current 
> > > > > > > > > > > > > > > > > > > > > > > > > > scheme, these components 
> > > > > > > > > > > > > > > > > > > > > > > > > > are naturally generated by 
> > > > > > > > > > > > > > > > > > > > > > > > > > the compiler, and the 
> > > > > > > > > > > > > > > > > > > > > > > > > > runtime only needs to know 
> > > > > > > > > > > > > > > > > > > > > > > > > > the base pointer, pointer, 
> > > > > > > > > > > > > > > > > > > > > > > > > > type, size. etc.
> > > > > > > > > > > > > > > > > > > > > > > > > With the current scheme, we 
> > > > > > > > > > > > > > > > > > > > > > > > > may end with the code 
> > > > > > > > > > > > > > > > > > > > > > > > > blowout. We need to generate 
> > > > > > > > > > > > > > > > > > > > > > > > > very similar code for 
> > > > > > > > > > > > > > > > > > > > > > > > > different types and 
> > > > > > > > > > > > > > > > > > > > > > > > > variables. The worst thing 
> > > > > > > > > > > > > > > > > > > > > > > > > here is that we will be 
> > > > > > > > > > > > > > > > > > > > > > > > > unable to optimize this huge 
> > > > > > > > > > > > > > > > > > > > > > > > > amount of code because the 
> > > > > > > > > > > > > > > > > > > > > > > > > codegen relies on the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > functions and the code cannot 
> > > > > > > > > > > > > > > > > > > > > > > > > be inlined. That's why I 
> > > > > > > > > > > > > > > > > > > > > > > > > would like to move as much as 
> > > > > > > > > > > > > > > > > > > > > > > > > possible code to the runtime 
> > > > > > > > > > > > > > > > > > > > > > > > > rather than to emit it in the 
> > > > > > > > > > > > > > > > > > > > > > > > > compiler. 
> > > > > > > > > > > > > > > > > > > > > > > > I understand your concerns. I 
> > > > > > > > > > > > > > > > > > > > > > > > think this is the best we can 
> > > > > > > > > > > > > > > > > > > > > > > > do right now.
> > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > The most worrisome case will be 
> > >

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 206895.
lildmh added a comment.

Change the type of size from `size_t` to `int64_t`, and rebase


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fope

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
Herald added subscribers: cfe-commits, jfb, arphaman, guansong, jholewinski.

Repository:
  rC Clang

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6230,6 +6230,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{extra tokens at the end of '#pragma omp declare mapper' are ignored}}
+
+#pragma omp declare mapper(++: vec v) map(v.len)// expected-error {{illegal identifier on 'omp declare mapper' directive}}
+#pragma omp declare mapper(id1: vec v) map(v.len, temp)

[PATCH] D67833: [OpenMP 5.0] Codegen support to pass user-defined mapper functions to runtime

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
Herald added subscribers: cfe-commits, guansong.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.

This patch implements the code generation to use OpenMP 5.0 declare mapper 
(e.g., user-defined mapper) constructs. It looks up the proper mapper function 
for each map, to, or from clause that has a user-defined mapper associated, and 
passes them to the OpenMP runtime function.
The design slides can be found at 
https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx


Repository:
  rC Clang

https://reviews.llvm.org/D67833

Files:
  include/clang/AST/OpenMPClause.h
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  test/OpenMP/capturing_in_templates.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_target_link_codegen.cpp
  test/OpenMP/target_is_device_ptr_codegen.cpp

Index: test/OpenMP/target_is_device_ptr_codegen.cpp
===
--- test/OpenMP/target_is_device_ptr_codegen.cpp
+++ test/OpenMP/target_is_device_ptr_codegen.cpp
@@ -49,7 +49,7 @@
   float *l;
   T *t;
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES00]]{{.+}}, {{.+}}[[TYPES00]]{{.+}})
+  // CK1-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES00]]{{.+}}, {{.+}}[[TYPES00]]{{.+}})
   // CK1-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
@@ -66,7 +66,7 @@
 ++g;
   }
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES01]]{{.+}}, {{.+}}[[TYPES01]]{{.+}})
+  // CK1-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES01]]{{.+}}, {{.+}}[[TYPES01]]{{.+}})
   // CK1-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
@@ -83,7 +83,7 @@
 ++l;
   }
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES02]]{{.+}}, {{.+}}[[TYPES02]]{{.+}})
+  // CK1-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES02]]{{.+}}, {{.+}}[[TYPES02]]{{.+}})
   // CK1-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
@@ -100,7 +100,7 @@
 ++t;
   }
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES03]]{{.+}}, {{.+}}[[TYPES03]]{{.+}})
+  // CK1-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES03]]{{.+}}, {{.+}}[[TYPES03]]{{.+}})
   // CK1-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
@@ -118,7 +118,7 @@
 ++lr;
   }
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES04]]{{.+}}, {{.+}}[[TYPES04]]{{.+}})
+  // CK1-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES04]]{{.+}}, {{.+}}[[TYPES04]]{{.+}})
   // CK1-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
@@ -136,7 +136,7 @@
 ++tr;
   }
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES05]]{{.+}}, {{.+}}[[TYPES05]]{{.+}})
+  // CK1-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES05]]{{.+}}, {{.+}}[[TYPES05]]{{.+}})
   // CK1-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, i32 0
   // CK1-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
@@ -154,7 +154,7 @@
 ++tr;
   }
 
-  // CK1-DAG: call i32 @__tgt_target(i64 {{

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh created this revision.
lildmh added reviewers: ABataev, Meinersbur, hfinkel, jdoerfert.
lildmh added a project: OpenMP.
Herald added subscribers: cfe-commits, guansong.
Herald added a project: clang.

This patches fixes the case when a user-defined mapper is attached to the 
elements of an array.


Repository:
  rC Clang

https://reviews.llvm.org/D67978

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -64,6 +64,7 @@
 {
 #pragma omp declare mapper(id: vec v) map(v.len)
   vec vv, v1;
+  vec arr[10];
 #pragma omp target map(mapper)  // expected-error {{use of undeclared identifier 'mapper'}}
   {}
 #pragma omp target map(mapper:vv)   // expected-error {{expected '(' after 'mapper'}}
@@ -82,7 +83,9 @@
   {}
 #pragma omp target map(mapper(N1::aa) alloc:vv) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}}
   {}
-#pragma omp target map(mapper(aa) to:vv) map(close mapper(aa) from:v1)
+#pragma omp target map(mapper(N1::aa) alloc:arr[0:2])   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}}
+  {}
+#pragma omp target map(mapper(aa) to:vv) map(close mapper(aa) from:v1) map(mapper(aa) to:arr[0])
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
@@ -96,8 +99,9 @@
 #pragma omp target update to(mapper(N1:: :vv)   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(N1::aa) :vv)// expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(ab):vv) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(ab):arr[0:2])   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(aa) a:vv)   // expected-warning {{missing ':' after ) - ignoring}}
-#pragma omp target update to(mapper(aa):vv)
+#pragma omp target update to(mapper(aa):vv) to(mapper(aa):arr[0])
 #pragma omp target update to(mapper(N1::stack::id) :vv)
 
 #pragma omp target update from(mapper)  // expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -109,8 +113,9 @@
 #pragma omp target update from(mapper(N1:: :vv) // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(N1::aa) :vv)  // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(ab):vv)   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(ab):arr[0:2]) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(aa) a:vv) // expected-warning {{missing ':' after ) - ignoring}}
-#pragma omp target update from(mapper(aa):vv)
+#pragma omp target update from(mapper(aa):vv) from(mapper(aa):arr[0])
 #pragma omp target update from(mapper(N1::stack::id) :vv)
 }
 #pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'id'}}
Index: test/OpenMP/declare_mapper_messages.c
===

[PATCH] D67833: [OpenMP 5.0] Codegen support to pass user-defined mapper functions to runtime

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 221578.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67833/new/

https://reviews.llvm.org/D67833

Files:
  include/clang/AST/OpenMPClause.h
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/capturing_in_templates.cpp
  test/OpenMP/declare_mapper_codegen.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/declare_target_link_codegen.cpp
  test/OpenMP/distribute_codegen.cpp
  test/OpenMP/distribute_firstprivate_codegen.cpp
  test/OpenMP/distribute_lastprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_codegen.cpp
  test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_if_codegen.cpp
  test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  test/OpenMP/distribute_parallel_for_private_codegen.cpp
  test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  test/OpenMP/distribute_parallel_for_reduction_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  test/OpenMP/distribute_private_codegen.cpp
  test/OpenMP/distribute_simd_codegen.cpp
  test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  test/OpenMP/distribute_simd_private_codegen.cpp
  test/OpenMP/distribute_simd_reduction_codegen.cpp
  test/OpenMP/nvptx_lambda_capturing.cpp
  test/OpenMP/nvptx_lambda_pointer_capturing.cpp
  test/OpenMP/nvptx_target_requires_unified_shared_memory.cpp
  test/OpenMP/openmp_offload_codegen.cpp
  test/OpenMP/target_codegen.cpp
  test/OpenMP/target_data_codegen.cpp
  test/OpenMP/target_depend_codegen.cpp
  test/OpenMP/target_enter_data_codegen.cpp
  test/OpenMP/target_enter_data_depend_codegen.cpp
  test/OpenMP/target_exit_data_codegen.cpp
  test/OpenMP/target_exit_data_depend_codegen.cpp
  test/OpenMP/target_firstprivate_codegen.cpp
  test/OpenMP/target_is_device_ptr_codegen.cpp
  test/OpenMP/target_map_codegen.cpp
  test/OpenMP/target_parallel_codegen.cpp
  test/OpenMP/target_parallel_depend_codegen.cpp
  test/OpenMP/target_parallel_for_codegen.cpp
  test/OpenMP/target_parallel_for_depend_codegen.cpp
  test/OpenMP/target_parallel_for_simd_codegen.cpp
  test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  test/OpenMP/target_parallel_if_codegen.cpp
  test/OpenMP/target_parallel_num_threads_codegen.cpp
  test/OpenMP/target_simd_codegen.cpp
  test/OpenMP/target_simd_depend_codegen.cpp
  test/OpenMP/target_teams_codegen.cpp
  test/OpenMP/target_teams_depend_codegen.cpp
  test/OpenMP/target_teams_distribute_codegen.cpp
  test/OpenMP/target_teams_distribute_collapse_codegen.cpp
  test/OpenMP/target_teams_distribute_depend_codegen.cpp
  test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  test/OpenMP/target_teams_distribute_firstprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_lastprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_collapse_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_dist_schedule_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_firstprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_lastprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_private_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_proc_bind_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_reduction_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_schedule_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_collapse_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  
test/OpenMP/target_teams_distribute_parallel_for_simd_dist_schedule_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_firstprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_lastprivate_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_private_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_proc_bind_codegen.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_reduction_codegen.cpp
  te

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Without this patch, it cannot recognize array with mapper, for instance, 
`#pragma omp target map(mapper(a),to: arr[0:2])` won't work without this patch.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67978#1681319 , @ABataev wrote:

> In D67978#1681318 , @lildmh wrote:
>
> > Without this patch, it cannot recognize array with mapper, for instance, 
> > `#pragma omp target map(mapper(a),to: arr[0:2])` won't work without this 
> > patch.
>
>
> What if we have a mapper for the array type?


Without this patch, it won't be able to find the mapper in this case, and Clang 
assumes no mapper. This patch fixes it, so the compiler can find the mapper in 
this case.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67978#1681388 , @ABataev wrote:

> In D67978#1681333 , @lildmh wrote:
>
> > In D67978#1681319 , @ABataev wrote:
> >
> > > In D67978#1681318 , @lildmh 
> > > wrote:
> > >
> > > > Without this patch, it cannot recognize array with mapper, for 
> > > > instance, `#pragma omp target map(mapper(a),to: arr[0:2])` won't work 
> > > > without this patch.
> > >
> > >
> > > What if we have a mapper for the array type?
> >
> >
> > Without this patch, it won't be able to find the mapper in this case, and 
> > Clang assumes no mapper. This patch fixes it, so the compiler can find the 
> > mapper in this case.
>
>
> It means, that you just ignore mappers for the array types, right?


Yes, it ignored mappers before, and this patch fixes it.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added a comment.

HI Alexey, the ast print test is already there. Because I didn't check the 
mapper for array type before, such code will always not report any error, and 
ast print test is correct. Codegen test belongs to the other patch I released. 
It fits that patch much better.




Comment at: lib/Sema/SemaOpenMP.cpp:14751
+assert(Type->getAsArrayTypeUnsafe() && "Expect to get a valid array type");
+Type = Type->getAsArrayTypeUnsafe()->getElementType().getCanonicalType();
+  }

ABataev wrote:
> Why do you want canonical type here? I think it is wrong. It drops all 
> language sugar like typedefs etc. But typedefs are not supported in mappers, 
> right?
I didn't see that the spec says typedef is not supported in mappers, so I 
suppose it should be supported. So I think `getCanonicalType` is necessary here?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added a comment.

In D67978#1683166 , @ABataev wrote:

> In D67978#1683146 , @lildmh wrote:
>
> > HI Alexey, the ast print test is already there. Because I didn't check the 
> > mapper for array type before, such code will always not report any error, 
> > and ast print test is correct. Codegen test belongs to the other patch I 
> > released. It fits that patch much better.
>
>
> How is this possible? If we did not have support for the array type, we could 
> not have correct handling of such types in successful tests.


The ast print for array with mapper was correct because the mapper id is still 
with the array type. Without this patch, the problem is it will not look up the 
mapper declaration associated with the id, and as a result, the codegen is not 
correct. I found this problem when I tested the codegen.




Comment at: lib/Sema/SemaOpenMP.cpp:14751
+assert(Type->getAsArrayTypeUnsafe() && "Expect to get a valid array type");
+Type = Type->getAsArrayTypeUnsafe()->getElementType().getCanonicalType();
+  }

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Why do you want canonical type here? I think it is wrong. It drops all 
> > > language sugar like typedefs etc. But typedefs are not supported in 
> > > mappers, right?
> > I didn't see that the spec says typedef is not supported in mappers, so I 
> > suppose it should be supported. So I think `getCanonicalType` is necessary 
> > here?
> Do we check the canonicaL type by default, for non-array type?
Yes, we use canonical type for non-array type, for instance, line 14935 in this 
file.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema for arrays

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67978#1684169 , @ABataev wrote:

> In D67978#1684104 , @lildmh wrote:
>
> > In D67978#1683166 , @ABataev wrote:
> >
> > > In D67978#1683146 , @lildmh 
> > > wrote:
> > >
> > > > HI Alexey, the ast print test is already there. Because I didn't check 
> > > > the mapper for array type before, such code will always not report any 
> > > > error, and ast print test is correct. Codegen test belongs to the other 
> > > > patch I released. It fits that patch much better.
> > >
> > >
> > > How is this possible? If we did not have support for the array type, we 
> > > could not have correct handling of such types in successful tests.
> >
> >
> > The ast print for array with mapper was correct because the mapper id is 
> > still with the array type. Without this patch, the problem is it will not 
> > look up the mapper declaration associated with the id, and as a result, the 
> > codegen is not correct. I found this problem when I tested the codegen.
>
>
> Then another one question. Why we don't emit the diagnostics if the original 
> type is not a class, struct or union? We just ignore this situation currently 
> but we should not. The error message must be emitted. I think that's why the 
> ast-print test works correctly though it should not.


We emit such diagnostic when mapper is declared, i.e., you cannot define a 
mapper for a non-class, non-struct, non-union type. It's in function 
`ActOnOpenMPDeclareMapperType` in SemaOpenMP.cpp. But I didn't emit such 
information where mapper is used. I will fix it in this patch. Thanks for 
getting this!


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 221990.
lildmh retitled this revision from "[OpenMP 5.0] Fix user-defined mapper lookup 
in sema for arrays" to "[OpenMP 5.0] Fix user-defined mapper lookup in sema".
lildmh edited the summary of this revision.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -64,6 +64,7 @@
 {
 #pragma omp declare mapper(id: vec v) map(v.len)
   vec vv, v1;
+  vec arr[10];
 #pragma omp target map(mapper)  // expected-error {{use of undeclared identifier 'mapper'}}
   {}
 #pragma omp target map(mapper:vv)   // expected-error {{expected '(' after 'mapper'}}
@@ -82,7 +83,9 @@
   {}
 #pragma omp target map(mapper(N1::aa) alloc:vv) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}}
   {}
-#pragma omp target map(mapper(aa) to:vv) map(close mapper(aa) from:v1)
+#pragma omp target map(mapper(N1::aa) alloc:arr[0:2])   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}}
+  {}
+#pragma omp target map(mapper(aa) to:vv) map(close mapper(aa) from:v1) map(mapper(aa) to:arr[0])
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
@@ -96,8 +99,9 @@
 #pragma omp target update to(mapper(N1:: :vv)   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(N1::aa) :vv)// expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(ab):vv) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(ab):arr[0:2])   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(aa) a:vv)   // expected-warning {{missing ':' after ) - ignoring}}
-#pragma omp target update to(mapper(aa):vv)
+#pragma omp target update to(mapper(aa):vv) to(mapper(aa):arr[0])
 #pragma omp target update to(mapper(N1::stack::id) :vv)
 
 #pragma omp target update from(mapper)  // expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -109,8 +113,9 @@
 #pragma omp target update from(mapper(N1:: :vv) // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(N1::aa) :vv)  // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(ab):vv)   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(ab):arr[0:2]) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(aa) a:vv) // expected-warning {{missing ':' after ) - ignoring}}
-#pragma omp target update from(mapper(aa):vv)
+#pragma omp target update from(mapper(aa):vv) from(mapper(aa):arr[0])
 #pragma omp target update from(mapper(N1::stack::id) :vv)
 }
 #pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'id'}}
Index: test/OpenMP/declare_mapper_messages.c
===

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 221991.
lildmh added a comment.

Fix mapper type checking


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp

Index: test/OpenMP/declare_mapper_messages.cpp
===
--- test/OpenMP/declare_mapper_messages.cpp
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -64,6 +64,7 @@
 {
 #pragma omp declare mapper(id: vec v) map(v.len)
   vec vv, v1;
+  vec arr[10];
 #pragma omp target map(mapper)  // expected-error {{use of undeclared identifier 'mapper'}}
   {}
 #pragma omp target map(mapper:vv)   // expected-error {{expected '(' after 'mapper'}}
@@ -82,7 +83,9 @@
   {}
 #pragma omp target map(mapper(N1::aa) alloc:vv) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}}
   {}
-#pragma omp target map(mapper(aa) to:vv) map(close mapper(aa) from:v1)
+#pragma omp target map(mapper(N1::aa) alloc:arr[0:2])   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}}
+  {}
+#pragma omp target map(mapper(aa) to:vv) map(close mapper(aa) from:v1) map(mapper(aa) to:arr[0])
   {}
 #pragma omp target map(mapper(N1::stack::id) to:vv)
   {}
@@ -96,8 +99,9 @@
 #pragma omp target update to(mapper(N1:: :vv)   // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(N1::aa) :vv)// expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(ab):vv) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update to(mapper(ab):arr[0:2])   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update to(mapper(aa) a:vv)   // expected-warning {{missing ':' after ) - ignoring}}
-#pragma omp target update to(mapper(aa):vv)
+#pragma omp target update to(mapper(aa):vv) to(mapper(aa):arr[0])
 #pragma omp target update to(mapper(N1::stack::id) :vv)
 
 #pragma omp target update from(mapper)  // expected-error {{expected '(' after 'mapper'}} expected-error {{expected expression}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
@@ -109,8 +113,9 @@
 #pragma omp target update from(mapper(N1:: :vv) // expected-error {{illegal OpenMP user-defined mapper identifier}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(N1::aa) :vv)  // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'aa'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(ab):vv)   // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
+#pragma omp target update from(mapper(ab):arr[0:2]) // expected-error {{cannot find a valid user-defined mapper for type 'vec' with name 'ab'}} expected-error {{expected at least one 'to' clause or 'from' clause specified to '#pragma omp target update'}}
 #pragma omp target update from(mapper(aa) a:vv) // expected-warning {{missing ':' after ) - ignoring}}
-#pragma omp target update from(mapper(aa):vv)
+#pragma omp target update from(mapper(aa):vv) from(mapper(aa):arr[0])
 #pragma omp target update from(mapper(N1::stack::id) :vv)
 }
 #pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{redefinition of user-defined mapper for type 'vec' with name 'id'}}
Index: test/OpenMP/declare_mapper_messages.c
===
--- test/OpenMP/declare_mapper_messages.c
+++ test/OpenMP/declare_mapper_messages.c
@@ -36,6 +36,8 @@
 {
 #pragma omp decla

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:14805
+  if (!Type->isStructureOrClassType() && !Type->isUnionType() &&
+  (MapperIdScopeSpec.isSet() || MapperId.getAsString() != "default")) {
+SemaRef.Diag(Loc, diag::err_omp_mapper_wrong_type);

ABataev wrote:
> Why need an additional check for scope and not "default" id? I don't see this 
> additional requirement in the standard. 
It's because every variable in map clauses will check this, including those are 
not struct, class, or union.

Using this, e.g., mapping an integer won't report error that it doesn't have a 
mapper.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67978: [OpenMP 5.0] Fix user-defined mapper lookup in sema

[Lingda Li via Phabricator via cfe-commits]

lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:14805
+  if (!Type->isStructureOrClassType() && !Type->isUnionType() &&
+  (MapperIdScopeSpec.isSet() || MapperId.getAsString() != "default")) {
+SemaRef.Diag(Loc, diag::err_omp_mapper_wrong_type);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Why need an additional check for scope and not "default" id? I don't see 
> > > this additional requirement in the standard. 
> > It's because every variable in map clauses will check this, including those 
> > are not struct, class, or union.
> > 
> > Using this, e.g., mapping an integer won't report error that it doesn't 
> > have a mapper.
> Maybe just move the check to the end of the function?
It will do some additional useless work if I move it to the end. I don't think 
it is necessary to move it back.

But if you believe it's better, I can do it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67978/new/

https://reviews.llvm.org/D67978



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits