[all-commits] [llvm/llvm-project] cfa413: [OpenMP] Don't reserve the generic mode warp on SP...

[Larry Meadows via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: cfa4135a9d324b3c539d9f874509ba03a8b0106f
      https://github.com/llvm/llvm-project/commit/cfa4135a9d324b3c539d9f874509ba03a8b0106f
  Author: Larry Meadows <Lawrence.Meadows at amd.com>
  Date:   2026-09-11 (Fri, 11 Sep 2026)

  Changed paths:
    M clang/test/OpenMP/ompx_attributes_codegen.cpp
    M clang/test/OpenMP/target_num_teams_num_threads_attributes.cpp
    M llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

  Log Message:
  -----------
  [OpenMP] Don't reserve the generic mode warp on SPIR-V (#222763)

#218790 widened a generic mode kernel's thread bound by a warp so that
the main
thread has one of its own. The bound is what lets the runtime's own warp
addition through: `getEffectiveNumThreads()` adds a warp and then clamps
to the
bound, so before that change the addition was clamped straight back off,
which
is why a `thread_limit` below one wavefront ended up with no workers.
Widening
the bound is the fix, and it is also what makes every generic mode
kernel launch
a warp wider than it used to.

`hasGridValue()` covers SPIR-V, so that geometry change reached Level
Zero.
@sarnex reports hangs and intermittent failures there and asked about a
revert
in
https://github.com/llvm/llvm-project/pull/222097#issuecomment-5609354538.
The
motivating bug was on AMDGPU, so this restricts the reservation to the
targets
it was written for and gives SPIR-V back the launch geometry it had
before.

Measured on gfx90a, generic mode, threads per block for a given
`thread_limit`:

| `thread_limit` | launched |
| --- | --- |
| 1 | 65 |
| 4 | 68 |
| 64 | 128 |
| 256 | 320 |
| 1024 | 1024 (clamped) |

Before #218790 each of those launched exactly `thread_limit`, because
the clamp
removed the runtime's warp again. SPIR-V goes back to that with this
patch:
`thread_limit(4)` writes a bound of 4 rather than 68, while AMDGPU keeps
68.

I have not reproduced the Level Zero failures — I have no Intel device,
and
OpenMP offload to `spirv64-amd-amdhsa` is not a working path, so AMD
hardware
cannot stand in. What this patch does establish is that SPIR-V's bound
returns
to its pre-#218790 value, so it undoes the geometry change whether or
not that
is the whole story. @sarnex, could you try it on the Level Zero runner?

This is a narrowing rather than a claim that SPIR-V never wants the
reserved
warp. Without it a SPIR-V `thread_limit` below a warp has the same
no-workers
problem #218790 fixed elsewhere; it is just not reachable today. If
Level Zero
grows the handling, this can come back.

Testing: `clang/test/OpenMP` 1613 passed,
`llvm/test/Transforms/{OpenMP,Attributor}`
263 passed, `LLVMFrontendTests` 1322 passed. Two tests needed updating,
both of
which encode SPIR-V thread bounds.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications