This is an archive of the discontinued LLVM Phabricator instance.

X86: fix frame offset calculation with mandatory tail calls
ClosedPublic

Authored by t.p.northover on Jul 21 2021, 7:22 AM.

Details

Reviewers
t.p.northover
Summary

If there's a region of the stack reserved for potential tail call arguments (only the case when we guarantee tail calls will be honoured), this is right next to the incoming stored return address, not necessarily next to the callee-saved area, so combining the two into a single figure leads to incorrect offsets in some edge cases.

This keeps the two concepts split and (hopefully) updates all users of getCalleeSavedFrameSize that need it. The notable exceptions are the stack-realignment code in emitEpilogue (~line 2117) which is where the bug came from, and Windows-ABI functions, because they don't guarantee tail calls so it should always be zero there.

Similarly, the code in getFrameIndexReference that dealt with this delta wasn't present on the realigned stack branch so I refactored it so that wasn't possible any more.

Diff Detail

Event Timeline

t.p.northover created this revision.Jul 21 2021, 7:22 AM
t.p.northover requested review of this revision.Jul 21 2021, 7:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2021, 7:22 AM
Gerolf added a subscriber: Gerolf.Jul 21 2021, 10:11 PM
Gerolf added inline comments.
llvm/lib/Target/X86/X86FrameLowering.cpp
2028

It seems here the code assume TailCallArgReserveSize is positive? This looks inconsistent to (X86FI->getCalleeSavedFrameSize() + TailCallArgReserveSize) in the NumBytes calculation in the function above.

llvm/test/CodeGen/X86/swifttail-realign.ll
1

Does this need more tests for the paths modified?

t.p.northover added inline comments.Jul 22 2021, 1:22 AM
llvm/lib/Target/X86/X86FrameLowering.cpp
2028

It is positive in both cases. Schematically the previous function has A - (B + C) but this one is A - B - C. I can switch to the first style here for consistency?

llvm/test/CodeGen/X86/swifttail-realign.ll
1

I think this actually covers both of the actual changes I made (the leaq offset and the [[RETADDR]] moves).

The frame lowering suggests you can get a base pointer without stack realignment, but it actually only seems to happen in one really obscure case with something called a "preallocated call". I think it's something to do with MSVC compatibility.

Thanks, Tim. LGTM.

t.p.northover accepted this revision.Aug 4 2021, 2:02 AM

Thanks Gerolf, committed as d7b0e5525a4e.

This revision is now accepted and ready to land.Aug 4 2021, 2:02 AM
t.p.northover closed this revision.Aug 4 2021, 2:03 AM