================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
