When looking for an available spill slot, the register scavenger would stop after finding the first one with no register assigned to it. That slot may have size and alignment that do not meet the requirements of the register that is to be spilled. Instead, find an available slot that is the closest in size and alignment to one that is needed to spill a register from RC.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
414 | Did you actually see cases where we should care? I would rather return the first matching one and be done with the loop. | |
439 | Given that we saw it can happen, I would go with a report_fatal_error. | |
test/CodeGen/Hexagon/reg-scavenger-valid-slot.ll | ||
3 |
| |
106 | Could you make the test smaller, e.g., via using inline asm to clobber registers? |
lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
414 | On Hexagon we can reserve spill slots for vectors (64-byte size/alignment) and integer registers (4/8-byte size/alignment). I'm concerned that depending on the order of reservation we can end up using a vector slot for an integer register. | |
439 | Will do. | |
test/CodeGen/Hexagon/reg-scavenger-valid-slot.ll | ||
106 | Let me see what I can do with inline asm. I haven't tried MIR with our backend so I'm not sure how much work it will be to get it to work. |
test/CodeGen/Hexagon/reg-scavenger-valid-slot.ll | ||
---|---|---|
106 | I need to keep enough registers live in a certain range. Turns out that vector register inputs and outputs are not yet implemented for inline-asm. I'll keep the code as is for now. |
test/CodeGen/Hexagon/reg-scavenger-valid-slot.ll | ||
---|---|---|
106 | What I mean is that our backend crashes in isel-lowering on inline-asm with vector inputs/outputs. |
Added a comment in RegisterScavenging.cpp explaining the motivation for the search loop modification.
Replaced the llvm_unreachable with a report_fatal_error. The message includes register name and register class name.
Applied instnamer to the test, added check lines, and a comment explaining what is being tested.
Created a shorter testcase.
test/CodeGen/Hexagon/reg-scavenger-valid-slot.ll | ||
---|---|---|
101 | I have fixed the inline-asm problem. |
lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
439–441 | At the second thought---wouldn't it be better to keep the "unreachable"? report_fatal_error does not print the call stack. |
lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
414 | What worries me is that we have a quadratic complexity here (#scavengedRegister x Scavenged.size()). | |
439–441 | We could do both maybe. |
llvm/trunk/lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
445 ↗ | (On Diff #57653) | I kept both. |
llvm/trunk/lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
445 ↗ | (On Diff #57653) | This makes no sense. llvm_unreachable() is an indication that this case cannot happen and the compiler will actually optimize for this. There is a high chance it remove the report_fatal_error() in this case. |
llvm/trunk/lib/CodeGen/RegisterScavenging.cpp | ||
---|---|---|
445 ↗ | (On Diff #57653) | With assertions enabled, llvm_unreachable is the more interesting way to terminate the program, since it will print the call stack. The report_fatal_error will never execute, which is fine. In the release mode, llvm_unreachable will expand to nothing (as per Quentin's earlier remark), but we still want the program to terminate with a meaningful message. It looks strange, but it was intentional. |
Did you actually see cases where we should care?
I would rather return the first matching one and be done with the loop.