[clang] [llvm] [AMDGPU] Convert AMDGPUResourceUsageAnalysis pass from Module to MF pass (PR #102913)
Janek van Oirschot via cfe-commits
cfe-commits at lists.llvm.org
Fri Aug 16 06:23:40 PDT 2024
================
@@ -75,10 +75,10 @@ bb.2:
store volatile i32 0, ptr addrspace(1) undef
ret void
}
-; DEFAULTSIZE: .amdhsa_private_segment_fixed_size 16
+; DEFAULTSIZE: .amdhsa_private_segment_fixed_size kernel_non_entry_block_static_alloca_uniformly_reached_align4.private_seg_size
; DEFAULTSIZE: ; ScratchSize: 16
-; ASSUME1024: .amdhsa_private_segment_fixed_size 1040
+; ASSUME1024: .amdhsa_private_segment_fixed_size kernel_non_entry_block_static_alloca_uniformly_reached_align4.private_seg_size
----------------
JanekvO wrote:
As a function's `private_segment_size` depends on itself, and all of its callees' propagated `private_segment_size` it may be the case that any of the callees' `private_segment_size` has yet to be analysed through `AMDGPUResourceUsageAnalysis`.
For example:
```
void foo() {
...
call bar
...
}
void bar() {
...
...
}
```
Where for `foo`, we know and can construct the calculation for its `private_segment_size` as
```
[foo's own private segment required size] + max(bar.private_segment_size, [any other of foo's called function's private_segment_size])
```
But because we are currently printing `foo`'s MachineFunction in `AMDGPUAsmPrinter`, we haven't analysed `bar`'s `private_segment_size` yet. This will eventually be known but as we need to print metadata for `foo`, it's already printed with `bar`'s `private_segment_size` placeholder.
TL;DR: cannot compute constant value yet, need to print symbolic representation.
https://github.com/llvm/llvm-project/pull/102913
More information about the cfe-commits
mailing list