en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/openmp/libomptarget/test/unified_shared_memory/associate_ptr.c#1f9e4370 [OpenMP][AMDGPU] Remove unneeded XFAILs List of files: /llvm-project-15.0.7/openmp/libomptarget/test/unified_shared_memory/associate_ptr.c Wed, 01 Sep 2021 21:59:40 +0000 Joel E. Denny <jdenny.ornl@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/openmp/libomptarget/test/unified_shared_memory/associate_ptr.c#d11bab0b [OpenMP] Use IsHostPtr where needed for targetDataBeginAs discussed in D105990, without this patch, `targetDataBegin`determines whether to transfer data (as opposed to assuming it's inshared memory) using the condition `!UseUSM || HasCloseModifier`.However, this condition is broken if use of discrete memory was forcedby `omp_target_associate_ptr`. This patch extends`unified_shared_memory/associate_ptr.c` to reveal this case, and itfixes it using `!IsHostPtr` in `DeviceTy::getTargetPointer` to replacethis condition.Reviewed By: grokosDifferential Revision: https://reviews.llvm.org/D107927 List of files: /llvm-project-15.0.7/openmp/libomptarget/test/unified_shared_memory/associate_ptr.c Wed, 01 Sep 2021 20:24:34 +0000 Joel E. Denny <jdenny.ornl@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/openmp/libomptarget/test/unified_shared_memory/associate_ptr.c#8e4836b2 [OpenMP] Use IsHostPtr where needed for targetDataEndAs discussed in D105990, without this patch, `targetDataEnd`determines whether to transfer data or delete a device mapping (asopposed to assuming it's in shared memory) using two differentconditions, each of which is broken for some cases:1. `!(UNIFIED_SHARED_MEMORY && TgtPtrBegin == HstPtrBegin)`: The broken case is rare: the device and host might happen to use the same address for their mapped allocations. I don't know how to write a test that's likely to reveal this case, but this patch does fix it, as discussed below.2. `!UNIFIED_SHARED_MEMORY || HasCloseModifier`: There are at least two broken cases: 1. The `close` modifier might have been specified on an `omp target enter data` but not the corresponding `omp target exit data`, which thus might falsely assume a mapping is in shared memory. The test `unified_shared_memory/close_enter_exit.c` already has a missing deletion as a result, and this patch adds a check for that. This patch also adds the new test `close_member.c` to reveal a missing transfer and deletion. 2. Use of discrete memory might have been forced by `omp_target_associate_ptr`, as in the test `unified_shared_memory/api.c`. In the current `targetDataEnd` implementation, this condition turns out not be used for this case: because the reference count is infinite, a transfer is possible only with an `always` modifier, and this condition is never used in that case. To ensure it's never used for that case in the future, this patch adds the test `unified_shared_memory/associate_ptr.c`.Fortunately, `DeviceTy::getTgtPtrBegin` already has a solution: itreports whether the allocation was found in shared memory via thevariable `IsHostPtr`.After this patch, `HasCloseModifier` is no longer used in`targetDataEnd`, and I wonder if the `close` modifier is ever usefulon an `omp target data end`.Reviewed By: grokosDifferential Revision: https://reviews.llvm.org/D107925 List of files: /llvm-project-15.0.7/openmp/libomptarget/test/unified_shared_memory/associate_ptr.c Wed, 01 Sep 2021 20:24:14 +0000 Joel E. Denny <jdenny.ornl@gmail.com>