2 # RUN: llvm-mc -filetype=obj -triple=arm64-apple-darwin %s -o %t.o
3 # RUN: %lld -arch arm64 -lSystem -o %t.out %t.o
5 ## Regression test for PR51578.
7 .subsections_via_symbols
9 .globl _f1, _f2, _f3, _f4, _f5, _f6
17 ## 6 * 4 = 24 bytes for branches
18 ## Currently leaves 12 bytes for one thunk, so 36 bytes.
19 ## Uses < instead of <=, so 40 bytes.
21 .global _spacer1, _spacer2
22 ## 0x8000000 is 128 MiB, one more than the forward branch limit,
23 ## distributed over two functions since our thunk insertion algorithm
24 ## can't deal with a single function that's 128 MiB.
25 ## We leave just enough room so that the old thunking algorithm finalized
26 ## both spacers when processing _f1 (24 bytes for the 4 bytes code for each
27 ## of the 6 _f functions, 12 bytes for one thunk, 4 bytes because the forward
28 ## branch range is 128 Mib - 4 bytes, and another 4 bytes because the algorithm
29 ## uses `<` instead of `<=`, for a total of 44 bytes slop.) Of the slop, 20
30 ## bytes are actually room for thunks.
31 ## _fn1-_fn6 aren't finalized because then there wouldn't be room for a thunk.
32 ## But when a thunk is inserted to jump from _f1 to _fn1, that needs 12 bytes
33 ## but _f2 is only 4 bytes later, so after _f1 there are only
34 ## 20-(12-4) = 12 bytes left, after _f2 only 12-(12-4) 4 bytes, and after
35 ## _f3 there's no more room for thunks and we can't make progress.
36 ## The fix is to leave room for many more thunks.
37 ## The same construction as this test case can defeat that too with enough
38 ## consecutive jumps, but in practice there aren't hundreds of consecutive
46 .globl _fn1, _fn2, _fn3, _fn4, _fn5, _fn6