This is an archive of the discontinued LLVM Phabricator instance.

Fix PR33031: Cannot scavenge register without an emergency spill slot.
ClosedPublic

Authored by kristof.beyls on May 23 2017, 7:50 AM.

Details

Summary

Also see the discussion on https://bugs.llvm.org/show_bug.cgi?id=33031.

This patch contains 2 conceptual changes:

  • Introducing option -reg-scavenging-always-use-spill-slot to enable writing maintainable tests for register scavenging.
  • Fix the underlying reason for PR33031: correct the estimate of maximum offset for instructions spilling/filling the stack.

I think both conceptual changes are implemented in a somewhat non-ideal way here, but those are the best engineering tradeoffs I've found so far.
Do the trade-offs taken here seem acceptable?

Diff Detail

Event Timeline

kristof.beyls created this revision.May 23 2017, 7:50 AM
srhines added inline comments.May 24 2017, 6:46 PM
lib/Target/AArch64/AArch64FrameLowering.cpp
1202

There is a subtle bug here. You have to use 255 for Limit in the estimateRSStackSizeLimit function now, because you aren't checking for >=. If the stack size is exactly 256 bytes, you wouldn't create the emergency spill slot, which is necessary because 256 can't be encoded as an offset.

MatzeB edited edge metadata.May 26 2017, 7:04 PM

Introducing option -reg-scavenging-always-use-spill-slot to enable writing maintainable tests for register scavenging.

That seems like a lot of machinery to test this. How about just adding a debug print and matching for that? Alternatively you should be able to match the extra spillslot in the stack: section of the mir file maybe?

lib/Target/AArch64/AArch64FrameLowering.cpp
140

Don't repeat the function name in the doxygen comment (old code does that but we don't do it anymore in new code).

143

Just do it? (Or remove the FIXME)

149

Please spell MachineBasicBlock instead of auto that is friendlier to the reader. We tend to only use auto in contexts where the type is immediately clear such as auto X = dyn_cast<SomeType>(...).
Same with the next loop.

162

Simply return 0;?

MatzeB added inline comments.May 26 2017, 7:05 PM
lib/Target/AArch64/AArch64FrameLowering.cpp
125

unnecessary?

Thanks all for the review comments!

I believe I've addressed them all in this updated patch.
I've dropped introducing the command line option -reg-scavenging-always-use-spill-slot. In the end I realized (should have realized that earlier), that with running a single pass in llc, it is possible to write a pretty stable test, even if register pressure must be extremely high in exactly the right place in the code.
I think the new regression test for this now looks nice, and definitely nice enough to not pollute the register scavenger with a special mode just for testing.

kristof.beyls marked 6 inline comments as done.May 29 2017, 7:53 AM
MatzeB accepted this revision.May 29 2017, 7:56 AM

LGTM

This revision is now accepted and ready to land.May 29 2017, 7:56 AM
MatzeB added inline comments.May 29 2017, 7:57 AM
lib/Target/AArch64/AArch64FrameLowering.cpp
160

How about putting an extra assert(Offset < 255); here to be sure?

MatzeB added inline comments.May 29 2017, 7:59 AM
lib/Target/AArch64/AArch64FrameLowering.cpp
160

or rather assert(Offset < 256); I guess.

kristof.beyls added inline comments.May 29 2017, 8:06 AM
lib/Target/AArch64/AArch64FrameLowering.cpp
160

The AArch64FrameOffsetCannotUpdate return value should already guarantee that Offset must remain 0; but it doesn't hurt to add the assert.
I'll do that and commit after I've finished running a bootstrap test on this patch.
The regression tests (obviously) and the test-suite pass.

... test-suite pass.

BTW: I tend to leaving testing of llvm test-suite to the bots, unless I have a reason to believe that a patch breaks it. Otherwise it's hard to get work done if you need an hour or more of testing before pushing a patch...

committed in r304196.