[llvm] RFC: Argpromotion of externally visible functions (PR #87731)

[David Goldblatt via llvm-commits]

davidtgoldblatt wrote:

> I mean, some callers might not be compiled with ThinLTO enabled, e.g. written in assembly, or another language. Or might just take the address of the function. Or the symbol might be exported from a shared library. So in general, inlining isn't reliable no matter what you do.

Yes, definitely; but note that this change relies on inlining for performance gains, but not correctness -- it's the wrapper function that gets the original's name and calling convention, so callers who are not visible to ThinLTO remain correct, and go through a relatively cheap wrapper instead (which in the worst case just needs to move around some arguments and jump to the renamed wrappee). My strong suspicion is that ThinLTO-visible -> ThinLTO-visible calls execute much more often than non-ThinLTO-visible -> ThinLTO-visible ones and so this is a good tradeoff for almost all programs.

> If this code were running as part of ThinLTO, instead of a pass running before ThinLTO, you could possibly detect those cases; the linker knows whether a symbol has external references.

I think even at ThinLTO link time, you don't necessarily know the answer, right? In the presence of sufficiently screwy dlopen-ings anything can happen. (Also just pragmatically: rewriting functions serially at thin-link time seems like a pretty heavy cost to pay).

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