[Mlir-commits] [llvm] [mlir] [OpenMPIRBuilder] Emit a dispatch loop for ordered worksharing loops on the device (PR #214263)

[Spencer Bryngelson]

sbryngelson wrote:

Stress-tested the dispatch path this routes to, since "untested" is fair: 48 configurations (31/256/1000 iterations x 2/8/64/128 threads x default/dynamic/static,4/guided), 5 runs each on gfx90a, device execution asserted. All 240 runs fail without this patch and pass with it. No measurable time difference between the two builds, though these are small kernels dominated by launch overhead, so I would not read that as a general statement about dispatch cost.

On implementing the device side instead: I looked at what that needs. The `*_static_loop_*` driver knows the iteration, but the ordered region is inside the loop body, so `__kmpc_ordered` has to block until a shared counter reaches the caller's iteration. It takes `(loc, tid)` with no iteration, so either its signature changes, which also affects clang since clang emits it on device today, or the driver stashes the current index in per-thread state for it to read. Either way threads end up waiting on each other inside a wavefront, and on AMDGPU the lock primitives are all `__builtin_trap()` with the comment "Don't have wavefront lane locks. Possibly can't have them." That is the same constraint that makes `setCriticalLock` elect a single lane rather than block. If there is a way around that I am not seeing, I am happy to do it that way instead.

What is wrong with the shortcut conceptually is just that the static-loop entries have no ordering mechanism at all, and the device `__kmpc_ordered` is an empty stub, so nothing orders. clang emits the dispatch entries for this construct on device, which is why the C equivalent is correct today; this makes flang do the same.

Worth saying plainly: `ordered` on a target construct is rare, and this is a correctness fix rather than a performance-relevant one. If you judge it not worth the complexity, I am fine closing it.

Also, point taken on the volume and the write-ups. I will keep descriptions to the defect, the fix and the test.


https://github.com/llvm/llvm-project/pull/214263