This is an archive of the discontinued LLVM Phabricator instance.

[LLD] Increase thunk pass limit
ClosedPublic

Authored by peter.smith on Mar 10 2023, 5:40 AM.

Details

Summary

In issue 61250 https://github.com/llvm/llvm-project/issues/61250 there is an example of a program that takes 17 passes to converge, which is 2 more than the current limit of 15. Analysis of the program shows a particular section that is made up of many roughly thunk sized chunks of code ending in a call to a symbol that needs a thunk. Due to the positioning of the section, at each pass a subset of the calls go out of range of their original thunk, needing a new one created, which then pushes more thunks out of range. This process eventually stops after 17 passes.

This patch is the simplest fix for the problem, which is to increase the pass limit. I've chosen to double it which should comfortably account for future cases like this, while only taking a few more seconds to reach the limit in case of non-convergence.

As discussed in the issue, there could be some additional work done to limit thunk reuse, this would potentially increase the number of thunks in the program but should speed up convergence. This could be done in a follow up patch.

Diff Detail

Event Timeline

peter.smith created this revision.Mar 10 2023, 5:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 10 2023, 5:40 AM
peter.smith requested review of this revision.Mar 10 2023, 5:40 AM
aeubanks accepted this revision.Mar 10 2023, 9:52 AM
This revision is now accepted and ready to land.Mar 10 2023, 9:52 AM
MaskRay accepted this revision.Mar 10 2023, 10:22 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 13 2023, 3:06 AM

In some other cases of iterative algorithms like this, we change the algorithm after a few passes to a version that converges faster. For example, you could consider adding extra padding after inserted thunks, in anticipation of the need for more thunks.

In some other cases of iterative algorithms like this, we change the algorithm after a few passes to a version that converges faster. For example, you could consider adding extra padding after inserted thunks, in anticipation of the need for more thunks.

We have something like that for when applying one of the erratum fixups that is sensitive to 4 KiB page boundaries, this can involve rounding up the size of the thunk section. It could be possible to switch something like that on after a number of passes that would likely prevent the slow creep of additional thunks.

Thanks for the suggestion!