lfmeadow wrote: If the three lines are widening the clamp in `getEffectiveNumThreads` — it does add the warp, and the `std::min(MaxNumThreads, ...)` on the next line takes it back off — I tried that. It launches the bigger block, and then faults.
`MaxNumThreads` is `KernelEnvironment.Configuration.MaxThreads`, which is also the number that became `amdgpu-flat-work-group-size`, and `.maxntid` on NVPTX, when the kernel was compiled. Widening the clamp puts 65 threads into a kernel whose metadata says `thread_limit(1)` means 1. The backend has already used that number: `AMDGPULowerIntrinsics` demotes a workgroup barrier to a wave barrier when the bound is no bigger than the wavefront, and `AMDGPUPromoteAlloca` sizes an LDS-promoted alloca from it. CUDA rejects a launch over `.maxntid` outright. So the runtime can't widen past the bound — the warp has to be in the number the compiler writes. If you meant something else, tell me which lines and I'll try it. https://github.com/llvm/llvm-project/pull/218790 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
