| Age | Commit message (Collapse) | Author |
|---|
|
#155348 (#164833)
This fixes strict weak ordering checks violations from #155348 when
running these two tests:
mlir/test/Dialect/OpenMP/omp-offload-privatization-prepare.mlir
mlir/test/Dialect/OpenMP/omp-offload-privatization-prepare-by-value.mlir
Sample error:
/stable/src/libcxx/include/__debug_utils/strict_weak_ordering_check.h:50: libc++ Hardening assertion !__comp(*__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering
This is because (x < x) should be false, not true, to meet the
irreflexibility property. (Note that .dominates(x, x) returns true.)
I'm afraid that even after this commit we can't guarantee a strict weak
ordering, because we can't guarantee transitivity of equivalence by
sorting with a strict dominance function. However the tests are not
failing anymore, and I am not at all familiar with this code so I will
leave this concern up to the original author for consideration. (Ideas
without any further context: I would consider a topological sort or
walking a dominator tree.)
Reference on std::sort and strict weak ordering:
https://danlark.org/2022/04/20/changing-stdsort-at-googles-scale-and-beyond/
|
|
`mapInfoOp.getMembers()` on line 258 is use-after-free, because
cloneModifyAndErase (line 255) erased `mapInfoOp`. Fix the issue by
replacing subsequent `mapInfoOp` usages with `clonedOp`.
Similarly, update `memberMapInfoOp` to avoid subsequent use-after-free.
|
|
These have been soft-deprecated since July:
https://discourse.llvm.org/t/psa-opty-create-now-with-100-more-tab-complete/87339
Add a deprecation attribute to prevent new uses from creeping in.
|
|
target-tasks (#155348)
This PR adds support for translation of the private clause on deferred
target tasks - that is `omp.target` operations with the `nowait` clause.
An offloading call for a deferred target-task is not blocking - the
offloading (target-generating) host task continues its execution after issuing the offloading
call. Therefore, the key problem we need to solve is to ensure that the
data needed for private variables to be initialized in the target task
persists even after the host task has completed.
We do this in a new pass called `PrepareForOMPOffloadPrivatizationPass`.
For a privatized variable that needs its host counterpart for
initialization (such as the shape of the data from the descriptor when
an allocatable is privatized or the value of the data when an
allocatable is firstprivatized),
- the pass allocates memory on the heap.
- it then initializes this memory by using the `init` and `copy` (for
firstprivate) regions of the corresponding `omp::PrivateClauseOp`.
- Finally the memory allocated on the heap is freed using the `dealloc`
region of the same `omp::PrivateClauseOp` instance. This step is not
straightforward though, because we cannot simply free the memory that's
going to be used by another thread without any synchronization. So, for
deallocation, we create a `omp.task` after the `omp.target` and
synchronize the two with a dummy dependency (using the `depend` clause).
In this newly created `omp.task` we do the deallocation.
|
