[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