[lld] [lld][elf] add safe-thunks in ELF (PR #126695)

[Peter Smith via llvm-commits]

https://github.com/smithp35 commented:

I've not gone over the code changes in detail. Mainly wanted to offer the perspective that this may get better results if it is integrated with the existing thunk generation, or at least delayed until addresses have been assigned. 

Right now if you have a particularly large binary, for example a fully instrumented chrome can get close to 200 MiB in size, then it is possible for the icf thunk to be out of range of the preserved function. This will cause another thunk to be generated using an indirect branch. We may have replaced `bl foo` in the original to `bl foo_icf`; `b foo_icf_longbranch`, `adrp; add; br`. Which is 16 extra bytes rather than 4, as well as an indirect branch (which may require a BTI to be inserted for another 4-bytes).

If handled later when addresses are known, then we would have more information on whether it is profitable to do the transformation or not. There's also the possibility of using the existing thunk generation code.

I think this would require something like ICF to label candidates that could be handled with thunks, but not removing them early, then handling them after addresses had been generated.

That's definitely more work to do, but I think it would get better results for the largest of binaries. An alternative perspective is that we advise that the option is not used on binaries over 128-MiB in size.  

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