[Mlir-commits] [clang] [llvm] [mlir] [OpenMP] Reserve the main thread's warp for generic mode kernels (PR #218790)

[Larry Meadows]

================
@@ -199,6 +200,17 @@ static const omp::GV &getGridValue(const Triple &T, Function *Kernel) {
         Kernel->getFnAttribute("target-features").getValueAsString();
     if (Features.count("+wavefrontsize64"))
       return omp::getAMDGPUGridValues<64>();
+    if (Features.count("+wavefrontsize32"))
+      return omp::getAMDGPUGridValues<32>();
+
+    // Clang sets no wavefront size on OpenMP device kernels, so ask the CPU.
+    StringRef CPU = Kernel->getFnAttribute("target-cpu").getValueAsString();
+    AMDGPU::GPUKind Kind = AMDGPU::parseArchAMDGCN(CPU);
+    if (Kind == AMDGPU::GK_NONE)
+      Kind = AMDGPU::getGPUKindFromSubArch(T.getSubArch());
+    if (Kind != AMDGPU::GK_NONE &&
+        !AMDGPU::getFeatureBitset(Kind).test(AMDGPU::FEAT_SUPPORTS_WAVE32))
+      return omp::getAMDGPUGridValues<64>();
     return omp::getAMDGPUGridValues<32>();
----------------
lfmeadow wrote:

Yes, good catch, fixed. With no `+wavefrontsize*` feature and an unrecognised `target-cpu`, `AMDGPU::parseArchAMDGCN` and the subarch lookup both return `GK_NONE`, and the old code fell through to wave32. On a wave64 device that widens the block by 32 and `BlockSize - WarpSize` underflows exactly as it did before the patch. An unknown target now gets wave64, since too large a block only wastes threads while too small a one is the bug.


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