Fix bug in MachO path where a frame index offset would not be reserved
for handling large frames when an extra non-used callee-save register
was saved. In the case where the extra register is reserved or not a
GPR (e.g. %FP in the MachO case), this would lead to the register
scavenger later failing when called from PrologEpilogInserter.
Details
Diff Detail
Event Timeline
I should add that I don't have a way to test the MachO path other than lit tests, so any additional testing would be appreciated.
Does it make sense to also include the testcase from the bugreport? It's fairly large, but anything smaller and the issue doesn't come up (bugpoint wasn't very helpful to reduce it further).
I spent some time trying to come up with a smaller test case without much luck. The problem is you need to generate enough spill code that the spill slot address offset doesn't fit in the load/store offset field, and have all GPRs live at the point where the too large spill offset occurs. I couldn't come up with a way to do that, though perhaps others have some idea here.
I could add the original test case, but it seems like it would be fairly fragile in that later changes in register allocation, etc. could easily make it no longer test what it was intended to test.
I know what you mean, I spend quite a bit of time to get the original test down to that size in the first place.
FYI: the original test case does not do test anything meaningful, it's only meant to crash on this particular bug.
Big tests are not the problem, but unstable tests are, especially around register allocation and scheduler. It could put people off-track in the future. I'm ok with this not having a test, too.
I'm ok either way. Geoff is right that later changes in reg allocator may make the test no longer exhibit the issue.
Waiting on Tim's input.
I think MIR-level tests are probably the long-term path for FrameLowering. I'm OK with skipping it on this occasion though.