Currently, when checking if a stack is "BigStack" or not, it doesn't count into spills and arguments. Therefore, LLVM won't reserve spill slot for this actually "BigStack". This may cause scavenger failure.
Details
- Reviewers
rengolin - Commits
- rG5b5501e81701: [ARM] Fix Scavenger assert due to underestimated stack size
rG74f12d31c1a5: [ARM] Fix Scavenger assert due to underestimated stack size
rG2373f769cefb: [ARM] Fix Scavenger assert due to underestimated stack size
rL268869: [ARM] Fix Scavenger assert due to underestimated stack size
rL268810: [ARM] Fix Scavenger assert due to underestimated stack size
rL268529: [ARM] Fix Scavenger assert due to underestimated stack size
Diff Detail
Event Timeline
Hi Weiming,
This looks ok to me, but I have a couple of comments.
Also, the test is a bit brittle. I understand it has to be big, but it could have a comment on it of what's it trying to test, so that if it breaks on an unrelated patch, people can follow up easier.
cheers,
--renato
lib/Target/ARM/ARMFrameLowering.cpp | ||
---|---|---|
1637 | Why does ArgStackSize depends on hasFP()? Also, what's the expected value for the stack limit here? I hope 16 is not a big fraction of it, or we'll be pessimising it on some corner cases. |
Thanks Renato. I will add comments to the test case. The test case has already been reduced by bugpoint and manual cleanup. It's still large because we need to stress the reg allocation to expose the issue.
lib/Target/ARM/ARMFrameLowering.cpp | ||
---|---|---|
1637 | estimateRSStackSizeLimit() will return 4096. When FP(r7) is used, it can use FP as a base reg to address parameters. So accessing parameters should be fine. |
I guess any kind of CHECK line will be very sensitive to the behaviour of middle and back end, so just passing the test should be ok, with the new comment.
LGTM, thanks!
Patch was reverted in http://llvm.org/viewvc/llvm-project?view=revision&revision=268536
Reverted with r268833
You can run msan build using https://github.com/google/sanitizers/wiki/MemorySanitizerBootstrappingClang
please add { } around this block, too.