[qt/clang/llvm]: Summary of bulk changes made
KDE Git Services - Bulk Change <[email protected]>
| Newsgroups | gmane.comp.kde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/hjagasiaAMD/swp-4-rp-limit'.
Changed from d982be9a856be3bf508554d0684639b09ae3d2c4 to c9e55b2b5abce00309c637a6d38beefbaf6c2b78
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.
This change contains the following new commits:
Git commit 6e940f2c3bf7065ac714cd78139af84397759a42 by Harsha Jagasia on 30/07/2026 at 17:22..
[AMDGPU] Allow MachinePipeliner to consider loops with large MIIs
The pipeliner rejects any loop whose minimum initiation interval (MII)
exceeds -pipeliner-max-mii, default 27. This can be too low for targets
with long instruction latencies, such as AMDGPU, where loops can have an
MII well above 27.
Add a PipelinerLoopInfo::allowLargeLoops() hook so a target can opt in
to a larger MII limit, and enable it for AMDGPU. Opted-in targets use a
limit of 256, while the generic default remains 27. An explicit
-pipeliner-max-mii still takes precedence.
The larger limit of 256 is chosen to cover the observed II distributions
of two AMDGPU workloads.
Composable Kernels:
II range count pct
0- 24 2305 36.7%
25- 49 1681 26.8%
50- 99 1582 25.3%
100-149 578 9.2%
150-299 64 1.0%
Triton:
II range count pct
96-128 19 50.0%
128-160 11 28.9%
160-192 2 5.3%
192-224 2 5.3%
224-256 4 10.5%
For these AMDGPU workloads, 256 captures the bulk of loops while retaining
a finite upper bound.
https://invent.kde.org/qt/clang/llvm/-/commit/6e940f2c3bf7065ac714cd78139af84397759a42
Git commit f4fb88b3b86c89a22e4c2d951eed392cd2b35580 by Harsha Jagasia on 30/07/2026 at 17:22..
[MachinePipeliner] Add PipelinerLoopInfo hooks to reuse the reg-pressure detector
The generic MachinePipeliner register-pressure detector (added in #74807)
was only reachable via the global -pipeliner-register-pressure flag, which
cannot be enabled per-target, and it judges pressure against generic
per-pressure-set limits. Add two PipelinerLoopInfo hooks so a target can
reuse that detector on its own terms:
- shouldLimitRegPressure(): A target can opt the loop into the detector without
the global flag.
- isScheduleRegPressureTooHigh(MaxSetPressure): let the target replace the
detector's generic per-pressure-set limit check with its own verdict, or
return nullopt to keep that check.
Both hooks default to preserving current behavior, so targets that do not
override them are unaffected.
Exercised by the AMDGPU adoption in the following commit.
https://invent.kde.org/qt/clang/llvm/-/commit/f4fb88b3b86c89a22e4c2d951eed392cd2b35580
Git commit c9e55b2b5abce00309c637a6d38beefbaf6c2b78 by Harsha Jagasia on 30/07/2026 at 17:22..
[AMDGPU] Limit register pressure of pipelined loops
Opt AMDGPU into the generic MachinePipeliner register-pressure detector via
shouldLimitRegPressure(), and supply an occupancy-aware verdict in
isScheduleRegPressureTooHigh(): reject a schedule whose SGPR or VGPR/AGPR
pressure would drop the kernel below its target occupancy, or exceed a
register class's addressability cap. On gfx90a+ VGPRs and AGPRs share one
register file, so their combined footprint is bounded together. These match
the limits GCNSchedStrategy enforces.
https://invent.kde.org/qt/clang/llvm/-/commit/c9e55b2b5abce00309c637a6d38beefbaf6c2b78