All those frame indices which are dead after sgpr spill should be removed from
the function frame. Othewise, there is a side effect such as re-mapping of free
frame index ids by the later pass(es) like "stack slot coloring" which in turn
could mess-up with the book keeping of "frame index to VGPR lane".
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| llvm/test/CodeGen/AMDGPU/sgpr-spill-incorrect-fi-bookkeeping-bug.ll | ||
|---|---|---|
| 8 | This doesn't do anything unless you run FileCheck. | |
| llvm/test/CodeGen/AMDGPU/sgpr-spill-incorrect-fi-bookkeeping-bug.ll | ||
|---|---|---|
| 2 | Does this work? It usually needs to be ... | FileCheck %s. | |
| llvm/test/CodeGen/AMDGPU/sgpr-spill-incorrect-fi-bookkeeping-bug.ll | ||
|---|---|---|
| 2 | No, it does not, it is again an incorrect check :( I have updated it. I am doing a clean build now, will run one round of lit test before pushing the updated fix. | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 459 | Isn't it possible to avoid this loop by handling the erase inside the original loop itself? | |
| llvm/test/CodeGen/AMDGPU/sgpr-spill-incorrect-fi-bookkeeping-bug.ll | ||
| 12 | Can you avoid all the unnamed variables? | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 451 | DenseSet, avoid std:: when possible. | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 451 | Will update it soon. | |
| 459 | As I understand it, it does not help. The llvm DensMap<>::erase() function does not return next iterator. So, erasing DensMap entries while iterating it seems to be *not* possible. Please let me know if you have any idea. | |
| llvm/test/CodeGen/AMDGPU/sgpr-spill-incorrect-fi-bookkeeping-bug.ll | ||
| 12 | I am coming up with altogether a different lit test. Will update it soon. | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 459 | If erase doesn't return the iterator, better retain this loop. Thanks. | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 459 | If you write the loop as for (auto &R : make_early_inc_range(SGPRToVGPRSpills)) then you can erase R inside the loop. | |
Do make_early_inc_range traversal of SGPRToVGPRSpills container so that
the entries can be erased while iterating itself.
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 459 | Thanks Jay. This is a useful LLVM related information that I was not aware of. | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 455 | erase(R) should be slightly more efficient as it does not have to do another lookup in the map. | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 455 | DenseMap<>::erase() (overloaded) functions takes either key or iterator as arguments. Here R is neither key nor iterator. It is an item (key value pair). https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/ADT/DenseMap.h#L302 | |
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 455 | Oh yes, you're right. So it would be slightly more efficient to use an iterator-based for loop, but neater to use a range-based for loop! I don't mind which you choose. | |
LGTM with a nitpick.
| llvm/lib/Target/AMDGPU/SIMachineFunctionInfo.cpp | ||
|---|---|---|
| 453 | The extra comment line. | |
DenseSet, avoid std:: when possible.