[llvm] [BOLT] Fix LongJmp layout estimation (PR #215416)

[Adam Bzowski via llvm-commits]

adam-bzowski-arm wrote:

Thank you for the review, @rafaelauler, but, unfortunately, I have realized that the patch does not fix the original issue I was investigating.

**Original issue**

The original motivation for this PR was processing a Chromium build with llvm-bolt, which resulted in several BOLT errors. All observed failures were caused by misestimating the 128 MiB range of AArch64 branch26/call26 instructions. Depending on when the out-of-range value is resolved, the failure appears either during MC emission:
```
<unknown>:0: error: fixup value out of range
BOLT-ERROR: Emission failed.
```
or during JITLink:
```
BOLT-ERROR: JITLink failed: In graph in-memory object file, section .text: relocation target 0x8400048 (<anonymous symbol>:0x400040 + 0x8000008) is out of range of Branch26PCRel fixup at address 0x400040 ($x, 0x400000 + 0x4)
```

**The missed change in BOLT**

While this was being investigated, `--lite=1` became the default on AArch64 on 28 July 2026 in [LLVM PR #205545](https://github.com/llvm/llvm-project/pull/205545). This changed the exercised code layout sufficiently that the Chromium failures disappeared, making it appear that the relatively small patch in this change had solved the original problem.

Retesting explicitly with `--lite=0` showed that it had not.

**A proposed solution**

The underlying problem is more fundamental: LongJmp’s tentative layout and the final emitter use different layout models. LongJmp currently treats the output as a single function stream separated by a guessed hot/cold frontier. In contrast, the emitter assigns each emitted function fragment to a named code section, orders those sections, applies their individual alignment requirements, and then allocates them.

These models are not always equivalent. We have investigated the issue and have a working solution. It requires a larger change that makes LongJmp’s tentative layout section-aware and matches the emitter’s section ordering and alignment model.

**What to do next?**

The current small patch still fixes valid layout-estimation discrepancies and has focused tests, but it does not solve the original Chromium failure. How would you prefer to proceed?
- Merge the smaller, independently useful fix and submit the section-aware layout change separately?
- Or replace this change with the larger section-aware implementation that addresses the original Chromium problem?

https://github.com/llvm/llvm-project/pull/215416