This is an archive of the discontinued LLVM Phabricator instance.

[lld/mac] Leave more room for thunks in thunk placement code

Authored by thakis on Aug 30 2021, 11:39 AM.



Fixes PR51578 in practice.

Currently there's only enough room for a single thunk, which for real-life code
isn't enough. The error case only happens when there are many branch statements
very close to each other (0 or 1 instructions apart), with the function at the
finalization barrier small.

There's a FIXME on what to do if we hit this case, but that suggestion sounds
complicated to me (see end of PR51578 comment 5 for why).

Instead, just leave more room for thunks. Chromium's unit_tests links fine with
room for 3 thunks. Leave room for 100, which should fix this for most cases in

There's little cost for leaving lots of room: This slop value only determines
when we finalize sections, and we insert thunks for forward jumps into
unfinalized sections. So leaving room means we'll need a few more thunks, but
the thunk jump range is 128 MiB while a single thunk is just 12 bytes.

For Chromium's unit_tests:
With a slop of 3: thunk calls = 355418, thunks = 10903
With a slop of 100: thunk calls = 355426, thunks = 10904

Chances are 100 is enough for all use cases we'll hit in practice, but even
bumping it to 1000 would probably be fine.

Diff Detail

Event Timeline

thakis created this revision.Aug 30 2021, 11:39 AM
Herald added a project: Restricted Project. · View Herald Transcript
thakis requested review of this revision.Aug 30 2021, 11:39 AM
int3 accepted this revision.Aug 30 2021, 12:32 PM
int3 added a subscriber: int3.

lgtm. I suppose it's a bit too awkward to unit test?


I'm confused about why the number of bytes for a call instruction is relevant here, since the call instruction will always be present regardless of whether the thunk is inserted

This revision is now accepted and ready to land.Aug 30 2021, 12:32 PM

I thought it'd be awkward to test, but it actually wasn't. Added a test.

Thanks for the review!


What matters is the distance to the instruction after the call instruction. If there are at least 12 bytes between call instructions, all's well. Since we're at a call instruction, there are guaranteed to be at least 4 bytes until the next call instruction. So we lose 8 bytes for every two directly consecutive calls.

Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2021, 7:09 PM