[PATCH] D51378: [OPENMP] Add support for nested 'declare target' directives

2018-08-28 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. Is there a way to tell if the header files have matching omp declare target/omp end declare target. The reason is if one of the header files is missing a matching omp end declare target all files which include it will end up having everything marked with

[PATCH] D51378: [OPENMP] Add support for nested 'declare target' directives

2018-08-30 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy accepted this revision. RaviNarayanaswamy added a comment. Ok. Thanks. Repository: rC Clang https://reviews.llvm.org/D51378 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D51378: [OPENMP] Add support for nested 'declare target' directives

2018-08-30 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. I did not see the code where check is done if Nestingdepth is 0 at end of compilation. Repository: rC Clang https://reviews.llvm.org/D51378 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D51378: [OPENMP] Add support for nested 'declare target' directives

2018-08-29 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. We should just go with generating an error if the DeclareTargetNestingLevel is not 0 at the end of compilation unit. Hard to detect if user accidentally forgot to have end declare in header file and had it in the include file or it was intentional.

[PATCH] D63010: [OpenMP] Add task alloc function

2019-06-14 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. LGTM Repository: rOMP OpenMP CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63010/new/ https://reviews.llvm.org/D63010 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D64375: [OpenMP][Docs] Provide implementation status details

2019-08-14 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added inline comments. Comment at: clang/docs/OpenMPSupport.rst:222-226 +| device extension | clause: reverse_offload | :good:`done` | D52780 |

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

2020-06-19 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. How do you plan to support #pragma omp target update to (arr[1:2][1:2][0:2], x, b[1:5][0:2]) Are you going to split this into 3 updates since your are using the arg fields. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D84422: [OpenMP] Fix `present` for exit from `omp target data`

2020-07-24 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. In D84422#2173372 , @jdenny wrote: > In D84422#2172898 , @jdenny wrote: > > > Has anyone clarified the motivation for this behavior? > > > I meant, is there any insight into why

[PATCH] D84422: [OpenMP] Fix `present` for exit from `omp target data`

2020-07-23 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. In D84422#2170285 , @grokos wrote: > What confuses me about this interpretation of the standard is the > inconsistency at `data exit`. So if we have an explicit `omp target exit data > map(present...)` then we should

[PATCH] D84422: [OpenMP] Fix `present` for exit from `omp target data`

2020-07-23 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. In D84422#2170667 , @grokos wrote: > So is the test case that motivated this patch illegal OpenMP code? > > #pragma omp target enter data map(alloc:i) > #pragma omp target data map(present, alloc: i) > { >

[PATCH] D106674: Runtime for Interop directive

2021-09-09 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added inline comments. Comment at: openmp/libomptarget/src/interop.cpp:198-201 + if (interop_type == kmp_interop_type_tasksync) { +__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias, + noalias_dep_list); + }

[PATCH] D106674: Runtime for Interop directive

2021-09-10 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added inline comments. Comment at: openmp/libomptarget/src/interop.cpp:198-201 + if (interop_type == kmp_interop_type_tasksync) { +__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias, + noalias_dep_list); + }

[PATCH] D106674: Runtime for Interop directive

2021-09-10 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added inline comments. Comment at: openmp/libomptarget/src/interop.cpp:198-201 + if (interop_type == kmp_interop_type_tasksync) { +__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias, + noalias_dep_list); + }

[PATCH] D106674: Runtime for Interop directive

2021-08-03 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added inline comments. Comment at: openmp/libomptarget/src/interop.cpp:194-196 + if (device_id == -1) { +device_id = omp_get_default_device(); + } Need to check if device is available for all 3 __tgt_interop_init/use/destroy

[PATCH] D106674: Runtime for Interop directive

2021-11-10 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy accepted this revision. RaviNarayanaswamy added a comment. This revision is now accepted and ready to land. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106674/new/ https://reviews.llvm.org/D106674

[PATCH] D157135: [OpenMP][Docs] Update OpenMP supported features table

2023-08-07 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157135/new/ https://reviews.llvm.org/D157135 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D157738: [OpenMP] Emit offloading entries for indirect target variables

2023-08-14 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added a comment. In D157738#4586465 , @JonChesterfield wrote: >> calling device functions via their associated host pointer > > What does this mean? Defining a function foo such that the host and each > individual target each have