There is no need to set a big default stack size for PAL code object indirect calls. The driver knows the max recursion depth, so it can compute a more accurate value from the minimum scratch size.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp | ||
---|---|---|
121–123 | Should use explicit brackets around the && clause. | |
122–124 | I think the logic here is that we treat PAL code objects the same as AMDHSL code objects >= 5 (PAL code objects have no amdgpu_code_object_version). So probably we should use if (AMDGPU::getCodeObjectVersion(M) >= AMDGPU::AMDHSA_COV5 || STI.getTargetTriple().getOS() == Triple::AMDPAL) for both, AssumedStackSizeForDynamicSizeObjects and AssumedStackSizeForExternalCall |
llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp | ||
---|---|---|
122–124 | Is some equivalent to the dynamic bit in the metadata emitted for pal? |
llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp | ||
---|---|---|
122–124 | We emit per-function metadata (https://llvm.org/docs/AMDGPUUsage.html#amdgpu-amdpal-code-object-shader-function-map-table). |
llvm/lib/Target/AMDGPU/AMDGPUResourceUsageAnalysis.cpp | ||
---|---|---|
122–124 | That metadata should be checked in the test |
llvm/test/CodeGen/AMDGPU/resource-usage-pal.ll | ||
---|---|---|
6 | Doesn't check a dynamic-is-present metadata field? |
Add comment to the test case
llvm/test/CodeGen/AMDGPU/resource-usage-pal.ll | ||
---|---|---|
6 | We don't have such flag in PAL abi. |
llvm/test/CodeGen/AMDGPU/resource-usage-pal.ll | ||
---|---|---|
6 | Then that is a problem? You would need one to know you need to add some extra? |
llvm/test/CodeGen/AMDGPU/resource-usage-pal.ll | ||
---|---|---|
6 | The amount of scratch that needs to be allocated is computed outside of LLVM in the graphics driver. The compute equivalent would be the linker/loader that sees all the functions that are linked together and also gets additional data like the maximum recursion depth. |
This patch is causing buildbot failures because the RUN line of the test case is invalid (missing colon symbol). This is now fixed by 9eea63bc9ccf5bd18a040cc028238ac4b49b77ea
Should use explicit brackets around the && clause.