[llvm] [MC,CodeGen] Update .prefalign for symbol-based preferred alignment (PR #184032)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> If [llvm-compile-time-tracker.com/compare.php?from=dddd06be8c3ed10eaef4f986ec4ceb828be7e789&to=f42b3383765cfaeea7a0654995bb6939278325f4&stat=instructions:u](https://llvm-compile-time-tracker.com/compare.php?from=dddd06be8c3ed10eaef4f986ec4ceb828be7e789&to=f42b3383765cfaeea7a0654995bb6939278325f4&stat=instructions:u) is the compile-time tracker run corresponding to this change, it looks like this is causing massive regressions at `-O0 -g`.

Thanks for catching this. Fixed by a new approach https://llvm-compile-time-tracker.com/compare.php?from=f1620e44412fd01a453f6f36d561bb395e1c0627&to=5aef56eb34727340877c59a7d24a4fc5b7383c52&stat=instructions:u and added a long paragraph at the end of the patch description about the subtle root cause.

    layoutPrefAlign is computed in layoutSection (not just relaxFragment)
    to avoid quadratic convergence. Alignment padding depends on
    offsetToAlignment(RawStart, Align), where RawStart is the fragment's
    offset. In relaxFragment, RawStart uses F.Offset from the previous
    layoutSection call. When an upstream alignment fragment changes padding,
    F.Offset becomes stale, so each relaxOnce iteration fixes only one more
    fragment — O(N) iterations for N fragments. By computing PrefAlign in
    layoutSection with the tracked Offset, all fragments get the correct
    RawStart in one pass. layoutPrefAlign walks forward to the end symbol
    to compute BodySize (summing fragment sizes), avoiding dependence on
    stale downstream symbol offsets.

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