| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[Flang][OpenMP][Dialect] Swap to using MLIR dialect enum to encode map flags (#164043) This PR shifts from using the LLVM OpenMP enumerator bit flags to an OpenMP dialect specific enumerator. This allows us to better represent map types that wouldn't be of interest to the LLVM backend and runtime in the dialect. Primarily things like ref_ptr/ref_ptee/ref_ptr_ptee/atach_none/attach_always/attach_auto which are of interest to the compiler for certrain transformations (primarily in the FIR transformation passes dealing with mapping), but the runtime has no need to know about them. It also means if another OpenMP implementation comes along they won't need to stick to the same bit flag system LLVM chose/do leg work to address it. | 9 个月前 | |
[flang][mlir] fix irreflexibility violation of strict weak ordering in #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/ | 9 个月前 | |
[Flang][mlir] - Translation of delayed privatization for deferred 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. | 9 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 |