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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Can you check if https://reviews.llvm.org/D84470 fixes the problem as this test 
doesn't work on my machine? If yes, please accept and upstream it since I don't 
have the permission.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

I couldn't reproduce this problem because all commands are ignored on my 
machine. Could you send the exact compiling and running commands?
In the IR files you sent me before, any idea where segfault happens?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67833#2166478 , @protze.joachim 
wrote:

> Starting with the commit of this patch, the libomptarget test 
> `llvm-project/openmp/libomptarget/test/offloading/target_depend_nowait.cpp` 
> fails. Here is a stacktrace of the segfault:
>
>   $ gdb target_depend_nowait.cpp.tmp-x86_64-pc-linux-gnu
>   (gdb) run
>   ...
>   Program received signal SIGSEGV, Segmentation fault.
>   (gdb) bt
>   #0  0x00400fcf in .omp_outlined._debug__ 
> (.global_tid.=0x2aaab96b9be0, .bound_tid.=0x2aaab96b9bd8) at 
> target_depend_nowait.cpp:22
>   #1  0x00401e8d in .omp_outlined..23 (.global_tid.=0x2aaab96b9be0, 
> .bound_tid.=0x2aaab96b9bd8) at target_depend_nowait.cpp:18
>   #2  0x2b574213 in __kmp_invoke_microtask () from libomp.so
>   #3  0x2b51338e in __kmp_invoke_task_func () from libomp.so
>   #4  0x2b5126bf in __kmp_launch_thread () from libomp.so
>   #5  0x2b55d3d0 in __kmp_launch_worker(void*) () from libomp.so
>   #6  0x2bbd6e65 in start_thread () from libpthread.so.0
>   #7  0x2bee988d in clone () from libc.so.6
>


Thanks. If possible, could you send me an IR generated before this patch and 
one after this patch, so I can probably see the problem?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67833#2161241 , @Meinersbur wrote:

> Seems that it already has been applied ;-)


Yes, thanks Michael. Hope everything goes well with you


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67833



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

[PATCH] D83959: Fix compiling warnings in OpenMP declare mapper codegen

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Thanks George!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83959



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Fix is at https://reviews.llvm.org/D83959
@Meinersbur Michael, could you please help upstream the patch above? Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67833#2155196 , @fhahn wrote:

> I think this change introduced the following warnings, where `auto &` is used 
> for types that are always copied. It would be great if you could take a look.
>
>   lvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:8011:24: warning: loop 
> variable 'L' is always a copy because the range of type 
> 'clang::OMPMappableExprListClause::const_component_lists_range'
>  (aka 
> 'iterator_range::const_component_lists_iterator>')
>  does not return a reference [-Wrange-loop-analysis]
> for (const auto  : C->component_lists()) {
>  ^
>   llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:8011:12: note: use 
> non-reference type 'std::__1::tuple llvm::ArrayRef, const 
> clang::ValueDecl *>'
> for (const auto  : C->component_lists()) {
>  ^~~
>   llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:8016:24: warning: loop 
> variable 'L' is always a copy because the range of type 
> 'clang::OMPMappableExprListClause::const_component_lists_range'
>  (aka 
> 'iterator_range::const_component_lists_iterator>')
>  does not return a reference [-Wrange-loop-analysis]
> for (const auto  : C->component_lists()) {
>  ^
>   llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:8016:12: note: use 
> non-reference type 'std::__1::tuple llvm::ArrayRef, const 
> clang::ValueDecl *>'
> for (const auto  : C->component_lists()) {
>  ^~~
>   llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:8032:24: warning: loop 
> variable 'L' is always a copy because the range of type 
> 'clang::OMPMappableExprListClause::const_component_lists_range'
>  (aka 
> 'iterator_range::const_component_lists_iterator>')
>  does not return a reference [-Wrange-loop-analysis]
> for (const auto  : C->component_lists()) {
>  ^
>   llvm-project/clang/lib/CodeGen/CGOpenMPRuntime.cpp:8032:12: note: use 
> non-reference type 'std::__1::tuple llvm::ArrayRef, const 
> clang::ValueDecl *>'
> for (const auto  : C->component_lists()) {
>  ^~~
>   3 warnings generated.
>


Thanks, I'll fix this soon. Basically `` needs to be `L` instead in those 3 
places. Since I don't have upload permission, it will be great if you can do 
the change quickly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

In D67833#2154312 , @grokos wrote:

> I tried to build clang with this patch and I get errors like:
>
>   CGOpenMPRuntime.cpp:9463:38: error: 
> ‘OMPRTL___tgt_target_teams_nowait_mapper’ was not declared in this scope
>   ? 
> OMPRTL___tgt_target_teams_nowait_mapper
>
>
> Where are these `OMPRTL___tgt_` symbols defined?


Sorry I forgot to include the llvm part. Please try again


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

https://reviews.llvm.org/D67833



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

[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 278344.
lildmh added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Include the llvm part


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

https://reviews.llvm.org/D67833

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/OpenMP/capturing_in_templates.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/declare_target_link_codegen.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_lambda_pointer_capturing.cpp
  clang/test/OpenMP/nvptx_target_requires_unified_shared_memory.cpp
  clang/test/OpenMP/openmp_offload_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_data_codegen.cpp
  clang/test/OpenMP/target_data_use_device_addr_codegen.cpp
  clang/test/OpenMP/target_defaultmap_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_device_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_firstprivate_codegen.cpp
  clang/test/OpenMP/target_is_device_ptr_codegen.cpp
  clang/test/OpenMP/target_map_codegen.cpp
  clang/test/OpenMP/target_map_member_expr_array_section_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_parallel_for_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_parallel_if_codegen.cpp
  clang/test/OpenMP/target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/target_parallel_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_simd_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_dist_schedule_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

@grokos Could you upstream this patch and the runtime patch neck to neck? 
Upstreaming one of them will break the OpenMP offloading. It will be nice if 
you can test this patch locally with the runtime patch. Thanks


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

https://reviews.llvm.org/D67833



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

[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 278291.
lildmh added a comment.

Update diff and pass test. Please accept


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

https://reviews.llvm.org/D67833

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/OpenMP/capturing_in_templates.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/declare_target_link_codegen.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_lambda_pointer_capturing.cpp
  clang/test/OpenMP/nvptx_target_requires_unified_shared_memory.cpp
  clang/test/OpenMP/openmp_offload_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_data_codegen.cpp
  clang/test/OpenMP/target_data_use_device_addr_codegen.cpp
  clang/test/OpenMP/target_defaultmap_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_device_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_firstprivate_codegen.cpp
  clang/test/OpenMP/target_is_device_ptr_codegen.cpp
  clang/test/OpenMP/target_map_codegen.cpp
  clang/test/OpenMP/target_map_member_expr_array_section_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_parallel_for_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_parallel_if_codegen.cpp
  clang/test/OpenMP/target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/target_parallel_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_simd_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_uses_allocators_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_dist_schedule_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_private_codegen.cpp
  

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

[Lingda Li via Phabricator via cfe-commits]

lildmh requested review of this revision.
lildmh added a comment.

I'll update the diff and please check and accept after that


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8981-8982
+  // Convert the size in bytes into the number of array elements.
+  Size = MapperCGF.Builder.CreateExactUDiv(
+  Size, MapperCGF.Builder.getInt64(ElementSize.getQuantity()));
   llvm::Value *PtrBegin = MapperCGF.Builder.CreateBitCast(

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > lildmh wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > So, we're still going to use number of elements for 
> > > > > > > > > > mappers? And pass it in the same parameter that in other 
> > > > > > > > > > cases is used as size in bytes? If so, point to it 
> > > > > > > > > > explicitly in the review for the runtime part so all are 
> > > > > > > > > > informed about it.
> > > > > > > > > From interface, the mapper function uses size in bytes now. 
> > > > > > > > > Inside, it needs number of elements to iterate through all 
> > > > > > > > > elements. This has no impact on the runtime part, since it 
> > > > > > > > > looks like normal mapping from the interface. All conversion 
> > > > > > > > > happens inside the mapper function which is completely 
> > > > > > > > > generated by the compiler.
> > > > > > > > Ok. Then why do we need to convert size in bytes to number of 
> > > > > > > > elements here?
> > > > > > > This is used to 1) see if we are going to map an array of 
> > > > > > > elements with mapper, and 2) iterate all to map them individually.
> > > > > > Could you point where we have this kind of analysis here? Because I 
> > > > > > don't see anything affected by this change in the patch.
> > > > > Is this a bug fix in the previous implementation?
> > > > The previous implementation assumes the size is the number of elements, 
> > > > and it works correctly under that assumption. Since we change the 
> > > > meaning of size here, I add this line of code so the previous 
> > > > implementation can work correctly in the new assumption that the size 
> > > > is the size in bytes.
> > > Ah, got it. Then, in general, looks good. Please, split the patches in 
> > > to, possibly, 2 NFC (one with using of the new functions + another one 
> > > for aggregating too many params into records) + another one with the new 
> > > functionality.
> > Okay, will do that. What do you think need to be done for the runtime patch 
> > D68100?
> Address comments and rebase, I think
The only left comment is to split it into 2 patches, I think.


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8981-8982
+  // Convert the size in bytes into the number of array elements.
+  Size = MapperCGF.Builder.CreateExactUDiv(
+  Size, MapperCGF.Builder.getInt64(ElementSize.getQuantity()));
   llvm::Value *PtrBegin = MapperCGF.Builder.CreateBitCast(

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > So, we're still going to use number of elements for mappers? 
> > > > > > > > And pass it in the same parameter that in other cases is used 
> > > > > > > > as size in bytes? If so, point to it explicitly in the review 
> > > > > > > > for the runtime part so all are informed about it.
> > > > > > > From interface, the mapper function uses size in bytes now. 
> > > > > > > Inside, it needs number of elements to iterate through all 
> > > > > > > elements. This has no impact on the runtime part, since it looks 
> > > > > > > like normal mapping from the interface. All conversion happens 
> > > > > > > inside the mapper function which is completely generated by the 
> > > > > > > compiler.
> > > > > > Ok. Then why do we need to convert size in bytes to number of 
> > > > > > elements here?
> > > > > This is used to 1) see if we are going to map an array of elements 
> > > > > with mapper, and 2) iterate all to map them individually.
> > > > Could you point where we have this kind of analysis here? Because I 
> > > > don't see anything affected by this change in the patch.
> > > Is this a bug fix in the previous implementation?
> > The previous implementation assumes the size is the number of elements, and 
> > it works correctly under that assumption. Since we change the meaning of 
> > size here, I add this line of code so the previous implementation can work 
> > correctly in the new assumption that the size is the size in bytes.
> Ah, got it. Then, in general, looks good. Please, split the patches in to, 
> possibly, 2 NFC (one with using of the new functions + another one for 
> aggregating too many params into records) + another one with the new 
> functionality.
Okay, will do that. What do you think need to be done for the runtime patch 
D68100?


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8981-8982
+  // Convert the size in bytes into the number of array elements.
+  Size = MapperCGF.Builder.CreateExactUDiv(
+  Size, MapperCGF.Builder.getInt64(ElementSize.getQuantity()));
   llvm::Value *PtrBegin = MapperCGF.Builder.CreateBitCast(

ABataev wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > So, we're still going to use number of elements for mappers? And 
> > > > > > pass it in the same parameter that in other cases is used as size 
> > > > > > in bytes? If so, point to it explicitly in the review for the 
> > > > > > runtime part so all are informed about it.
> > > > > From interface, the mapper function uses size in bytes now. Inside, 
> > > > > it needs number of elements to iterate through all elements. This has 
> > > > > no impact on the runtime part, since it looks like normal mapping 
> > > > > from the interface. All conversion happens inside the mapper function 
> > > > > which is completely generated by the compiler.
> > > > Ok. Then why do we need to convert size in bytes to number of elements 
> > > > here?
> > > This is used to 1) see if we are going to map an array of elements with 
> > > mapper, and 2) iterate all to map them individually.
> > Could you point where we have this kind of analysis here? Because I don't 
> > see anything affected by this change in the patch.
> Is this a bug fix in the previous implementation?
The previous implementation assumes the size is the number of elements, and it 
works correctly under that assumption. Since we change the meaning of size 
here, I add this line of code so the previous implementation can work correctly 
in the new assumption that the size is the size in bytes.


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

https://reviews.llvm.org/D67833



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

[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 234579.
lildmh added a comment.

Change the function name


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

https://reviews.llvm.org/D67833

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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8986
   CGM.getTypes().ConvertTypeForMem(C.getPointerType(PtrTy)));
   llvm::Value *PtrEnd = MapperCGF.Builder.CreateGEP(PtrBegin, Size);
   llvm::Value *MapType = MapperCGF.EmitLoadOfScalar(

`Size` is used to compute the last element position, which is used as the loop 
boundary.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:9207
   llvm::Value *IsArray = MapperCGF.Builder.CreateICmpSGE(
   Size, MapperCGF.Builder.getInt64(1), "omp.arrayinit.isarray");
   MapperCGF.Builder.CreateCondBr(IsArray, IsDeleteBB, ExitBB);

`Size` is used to see if this is an array.


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8981-8982
+  // Convert the size in bytes into the number of array elements.
+  Size = MapperCGF.Builder.CreateExactUDiv(
+  Size, MapperCGF.Builder.getInt64(ElementSize.getQuantity()));
   llvm::Value *PtrBegin = MapperCGF.Builder.CreateBitCast(

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > So, we're still going to use number of elements for mappers? And pass it 
> > > in the same parameter that in other cases is used as size in bytes? If 
> > > so, point to it explicitly in the review for the runtime part so all are 
> > > informed about it.
> > From interface, the mapper function uses size in bytes now. Inside, it 
> > needs number of elements to iterate through all elements. This has no 
> > impact on the runtime part, since it looks like normal mapping from the 
> > interface. All conversion happens inside the mapper function which is 
> > completely generated by the compiler.
> Ok. Then why do we need to convert size in bytes to number of elements here?
This is used to 1) see if we are going to map an array of elements with mapper, 
and 2) iterate all to map them individually.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:9244
+llvm::Function *
+CGOpenMPRuntime::getUserDefinedMapperFunc(const OMPDeclareMapperDecl *D) {
+  auto I = UDMMap.find(D);

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > `getOrEmitUserDefinedMapperFunc`?
> > I guess `getUserDefinedMapperFunc` is a better name? Because the user uses 
> > this function to get the mapper function. Emitting a mapper function is a 
> > side effect.
> I meant something like `getOrCreate...` but it is up to you.
Okay, sounds good


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:8981-8982
+  // Convert the size in bytes into the number of array elements.
+  Size = MapperCGF.Builder.CreateExactUDiv(
+  Size, MapperCGF.Builder.getInt64(ElementSize.getQuantity()));
   llvm::Value *PtrBegin = MapperCGF.Builder.CreateBitCast(

ABataev wrote:
> So, we're still going to use number of elements for mappers? And pass it in 
> the same parameter that in other cases is used as size in bytes? If so, point 
> to it explicitly in the review for the runtime part so all are informed about 
> it.
From interface, the mapper function uses size in bytes now. Inside, it needs 
number of elements to iterate through all elements. This has no impact on the 
runtime part, since it looks like normal mapping from the interface. All 
conversion happens inside the mapper function which is completely generated by 
the compiler.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:9244
+llvm::Function *
+CGOpenMPRuntime::getUserDefinedMapperFunc(const OMPDeclareMapperDecl *D) {
+  auto I = UDMMap.find(D);

ABataev wrote:
> `getOrEmitUserDefinedMapperFunc`?
I guess `getUserDefinedMapperFunc` is a better name? Because the user uses this 
function to get the mapper function. Emitting a mapper function is a side 
effect.


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

https://reviews.llvm.org/D67833



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

[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 234554.
lildmh marked 3 inline comments as done.
lildmh added a comment.

Address Alexey's comments to change mapper function size and refactor code


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

https://reviews.llvm.org/D67833

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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/AST/OpenMPClause.h:4918
 const OMPMappableExprListSizeTy )
-  : OMPMappableExprListClause(OMPC_map, Locs, Sizes, ,
-  ),
+  : OMPMappableExprListClause(OMPC_map, Locs, Sizes, /*HasMapper=*/true,
+  , ),

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > Do we really need to set `HasMapper` to `true` unconditionally here 
> > > > > and in other places?
> > > > For `map`, `to`, and `from` clauses, they can have mappers, so it's set 
> > > > to `true`. For `is_device_ptr` and `use_device_ptr`, it's set to 
> > > > `false`.
> > > So, it completely depends on the clause kind, right? If so, can we just 
> > > remove it and rely on the clause kind?
> > This is used in `OMPMappableExprListClause` which is inherited by all these 
> > clauses. Do you mean to check the template type there to get the clause 
> > kind?
> I see. I think it is better to rename it to `ClauseSupportsMapper` (or 
> something like this) and make it `const`. Currently, it is confusing. I 
> thought that this flag shows the use of the mapper in the clause.
Ok, will do that


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/AST/OpenMPClause.h:4918
 const OMPMappableExprListSizeTy )
-  : OMPMappableExprListClause(OMPC_map, Locs, Sizes, ,
-  ),
+  : OMPMappableExprListClause(OMPC_map, Locs, Sizes, /*HasMapper=*/true,
+  , ),

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Do we really need to set `HasMapper` to `true` unconditionally here and 
> > > in other places?
> > For `map`, `to`, and `from` clauses, they can have mappers, so it's set to 
> > `true`. For `is_device_ptr` and `use_device_ptr`, it's set to `false`.
> So, it completely depends on the clause kind, right? If so, can we just 
> remove it and rely on the clause kind?
This is used in `OMPMappableExprListClause` which is inherited by all these 
clauses. Do you mean to check the template type there to get the clause kind?


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

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

Alexey, thanks for the review




Comment at: clang/include/clang/AST/OpenMPClause.h:4918
 const OMPMappableExprListSizeTy )
-  : OMPMappableExprListClause(OMPC_map, Locs, Sizes, ,
-  ),
+  : OMPMappableExprListClause(OMPC_map, Locs, Sizes, /*HasMapper=*/true,
+  , ),

ABataev wrote:
> Do we really need to set `HasMapper` to `true` unconditionally here and in 
> other places?
For `map`, `to`, and `from` clauses, they can have mappers, so it's set to 
`true`. For `is_device_ptr` and `use_device_ptr`, it's set to `false`.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7388
 
-  llvm::Value *getExprTypeSize(const Expr *E) const {
+  llvm::Value *getExprTypeSize(const Expr *E, bool hasMapper) const {
 QualType ExprTy = E->getType().getCanonicalType();

ABataev wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > ABataev wrote:
> > > > > CamelCase
> > > > Seems to me, with mapper you're changing the contract of this function. 
> > > > It is supposed to return the size in bytes, with Mapper it returns just 
> > > > number of elements. Bad decision. Better to convert size in bytes to 
> > > > number of elements in place where you need it.
> > > Yes. The reason why I did this is I found this is the single place that I 
> > > can consider all situations. Otherwise, I need to divide the size by the 
> > > element size in other places. Since this function has discussed all 
> > > situations for the element size, I will need to duplicate the work 
> > > elsewhere if I don't do it here. The latter solution is not good for code 
> > > mountainous I think.
> > Changing the original function contract is also not the best solution. 
> > Better to introduce the new function. If some of the code can be reused, 
> > need to factor out the common code and reuse it in the old function and the 
> > new one.
> Also, additional question. Does it mean that we pass to the runtime functions 
> different values in different situations: in one case we pass size in bytes, 
> with mappers - number of elements? If so, it is a very bad idea caused by bad 
> design. We need to pass either size in bytes, or number of elements in this 
> argument.
Yes, the current design is like this. Let me see how to make it better



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8821-8822
+
+// No user-defined mapper for default mapping.
+CurMappers.push_back(nullptr);
   }

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > In general, there should not be branch for default mapping during the 
> > > codegen, the implicit map clauses must be generated in sema.
> > Not sure where this code will be used. I guess it's still correct to add a 
> > null to the mappers here?
> I mean, that in general, it would be good to see here some kind of an 
> assertion. Almost all situations must be resolved in Sema.
Okay, I guess it's not the work of this patch


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

https://reviews.llvm.org/D67833



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

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

I'll split the patch into 2 later




Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7388
 
-  llvm::Value *getExprTypeSize(const Expr *E) const {
+  llvm::Value *getExprTypeSize(const Expr *E, bool hasMapper) const {
 QualType ExprTy = E->getType().getCanonicalType();

ABataev wrote:
> ABataev wrote:
> > CamelCase
> Seems to me, with mapper you're changing the contract of this function. It is 
> supposed to return the size in bytes, with Mapper it returns just number of 
> elements. Bad decision. Better to convert size in bytes to number of elements 
> in place where you need it.
Yes. The reason why I did this is I found this is the single place that I can 
consider all situations. Otherwise, I need to divide the size by the element 
size in other places. Since this function has discussed all situations for the 
element size, I will need to duplicate the work elsewhere if I don't do it 
here. The latter solution is not good for code mountainous I think.



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:7564-7573
   void generateInfoForComponentList(
-  OpenMPMapClauseKind MapType,
-  ArrayRef MapModifiers,
+  OpenMPMapClauseKind MapType, ArrayRef 
MapModifiers,
   OMPClauseMappableExprCommon::MappableExprComponentListRef Components,
   MapBaseValuesArrayTy , MapValuesArrayTy ,
   MapValuesArrayTy , MapFlagsArrayTy ,
-  StructRangeInfoTy , bool IsFirstComponentList,
-  bool IsImplicit,
+  MapMappersArrayTy , StructRangeInfoTy ,
+  bool IsFirstComponentList, bool IsImplicit,

ABataev wrote:
> Too many params in the function, worth thinking about wrapping them in a 
> record.
Maybe not in this patch?



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8821-8822
+
+// No user-defined mapper for default mapping.
+CurMappers.push_back(nullptr);
   }

ABataev wrote:
> In general, there should not be branch for default mapping during the 
> codegen, the implicit map clauses must be generated in sema.
Not sure where this code will be used. I guess it's still correct to add a null 
to the mappers here?



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8953-8955
+  llvm::Value *M = CGF.Builder.CreateConstInBoundsGEP2_32(
+  llvm::ArrayType::get(CGM.VoidPtrTy, Info.NumberOfPtrs),
+  Info.MappersArray, 0, I);

ABataev wrote:
> Better to use `Builder.CreateConstArrayGEP` 
I saw all the other places are using `CreateConstInBoundsGEP2_32` to get sizes, 
types, etc. So I kept it consistent here. Maybe these modifications should be 
in a future patch?



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8956-8957
+  Info.MappersArray, 0, I);
+  M = CGF.Builder.CreatePointerBitCastOrAddrSpaceCast(
+  M, MFunc->getType()->getPointerTo(/*AddrSpace=*/0));
+  Address MAddr(M, Ctx.getTypeAlignInChars(Ctx.VoidPtrTy));

ABataev wrote:
> Easier cast function to the `voidptr`, I think
Again, this is to keep it consistent with previous code above?



Comment at: lib/CodeGen/CGOpenMPRuntime.cpp:8991-8994
+  MappersArrayArg = CGF.Builder.CreateConstInBoundsGEP2_32(
+  llvm::ArrayType::get(CGM.VoidPtrTy, Info.NumberOfPtrs),
+  Info.MappersArray,
+  /*Idx0=*/0, /*Idx1=*/0);

ABataev wrote:
> Hmm, just cast of the `Info.MappersArray` to the correct type if all indices 
> are `0`?
Again, this is to keep consistent with previous code?


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

https://reviews.llvm.org/D67833



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

[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 234113.
lildmh marked 28 inline comments as done.
lildmh added a comment.

Rebase and address comments


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

https://reviews.llvm.org/D67833

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

[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 229200.
lildmh added a comment.

Rebase


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
  test/OpenMP/capturing_in_templates.cpp
  test/OpenMP/declare_mapper_codegen.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
  test/OpenMP/target_teams_distribute_parallel_for_simd_schedule_codegen.cpp
  

[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 222066.
lildmh added a comment.

Rebase


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
  test/OpenMP/capturing_in_templates.cpp
  test/OpenMP/declare_mapper_codegen.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
  test/OpenMP/target_teams_distribute_parallel_for_simd_schedule_codegen.cpp
  

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

[Lingda Li via Phabricator via cfe-commits]

lildmh added a comment.

Thanks Alexey! Please check the other 2 mapper patches at 
https://reviews.llvm.org/D67833 and https://reviews.llvm.org/D68100 when you 
have time. They should be the last mapper patches.


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:
> > > lildmh wrote:
> > > > 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.
> > > Could you add tests for this new functionality?
> > I already add the test in declare_mapper_message.c. I think nothing is 
> > needed for ast print test.
> I mean, for this error message. I did not see the change in the tests when 
> you added this new check.
line 55, 68, 79 in declare_mapper_messages.c is added for this new check.


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:
> > > 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.
> Could you add tests for this new functionality?
I already add the test in declare_mapper_message.c. I think nothing is needed 
for ast print test.


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

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

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

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

[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 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] 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: 

[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 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: 

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

[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 ,
+  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 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 

[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 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:
> 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 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 

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

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

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

[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 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:
> > > > > > > > > > > > > > > > > > > > > > > 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:
> > > > > > > > > > > > > > > > > > > > > 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 

[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 

[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:
> > > > > > > > > > > > > > > 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 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 

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

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

[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 

[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 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 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 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 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:
> 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 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: 

[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 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:
> > > 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:
> 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 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 

[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: 

[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 

[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] 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 

[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 ,
+MapValuesArrayTy ,

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

[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] 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 ')'}} 

[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] 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 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'}}

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