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

[Larry Meadows via All-commits]

  Branch: refs/heads/users/lfmeadow/spirv-generic-warp
  Home:   https://github.com/llvm/llvm-project
  Commit: cff760b3117a7ffc8ee3f8321fa6a1eeb82c7543
      https://github.com/llvm/llvm-project/commit/cff760b3117a7ffc8ee3f8321fa6a1eeb82c7543
  Author: Larry Meadows <Lawrence.Meadows at amd.com>
  Date:   2026-09-10 (Thu, 10 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

218790 widened a generic mode kernel's thread bound by a warp so 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 clamps to the bound,
so before that change the addition was clamped straight back off and a
thread_limit below one wavefront was left with no workers. Widening the bound is
what fixes that, and it is also what makes every generic mode launch a warp
wider than it used to be.

hasGridValue() covers SPIR-V, so that geometry change reached Level Zero, where
sarnex reports hangs and intermittent failures. The motivating bug was on
AMDGPU. Restrict the reservation to the targets it was written for and leave
SPIR-V with the launch geometry it had before.

Measured on gfx90a, generic mode, threads per block for a given thread_limit:
1 -> 65, 4 -> 68, 64 -> 128, 256 -> 320, 1024 -> 1024. Before 218790 each of
those launched exactly thread_limit. SPIR-V now goes back to the latter.

This is a narrowing, not a claim that SPIR-V never wants the reserved warp. If
Level Zero grows the handling it can come back.



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