diff options
author | Lucas Ramirez <11032120+lucas-rami@users.noreply.github.com> | 2025-08-08 14:26:04 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-08-08 14:26:04 +0200 |
commit | 83c308f014da00cadbbe9ac7c8fe8a48ff777b76 (patch) | |
tree | 58ad7a7d4b6c027bff2bd596a31af184c23fe044 /llvm/lib/Bitcode/Writer/BitcodeWriter.cpp | |
parent | ab7281d8969152a2cb0f302fe645e99e58e6d281 (diff) | |
download | llvm-83c308f014da00cadbbe9ac7c8fe8a48ff777b76.zip llvm-83c308f014da00cadbbe9ac7c8fe8a48ff777b76.tar.gz llvm-83c308f014da00cadbbe9ac7c8fe8a48ff777b76.tar.bz2 |
[AMDGPU][Scheduler] Consistent occupancy calculation during rematerialization (#149224)
The `RPTarget`'s way of determining whether VGPRs are beneficial to save
and whether the target has been reached w.r.t. VGPR usage currently
assumes, if `CombinedVGPRSavings` is true, that free slots in one VGPR
RC can always be used for the other. Implicitly, this makes the
rematerialization stage (only current user of `RPTarget`) follow a
different occupancy calculation than the "regular one" that the
scheduler uses, one that assumes that ArchVGPR/AGPR usage can be
balanced perfectly and at no cost, which is untrue in general. This
ultimately yields suboptimal rematerialization decisions that require
cross-VGPR-RC copies unnecessarily.
This fixes that, making the `RPTarget`'s internal model of occupancy
consistent with the regular one. The `CombinedVGPRSavings` flag is
removed, and a form of cross-VGPR-RC saving implemented only for unified
RFs, which is where it makes the most sense. Only when the amount of
free VGPRs in a given VGPR RC (ArchVPGR or AGPR) is lower than the
excess VGPR usage in the other VGPR RC does the `RPTarget` consider that
a pressure reduction in the former will be beneficial to the latter.
Diffstat (limited to 'llvm/lib/Bitcode/Writer/BitcodeWriter.cpp')
0 files changed, 0 insertions, 0 deletions