[llvm] [ThinLTO] Don't mark calloc function dead (PR #72673)

[Teresa Johnson via llvm-commits]

teresajohnson wrote:

> Updated test cases
> 
> > > The problem arises only when two (or more) libcalls are folded into one (or more) other libcalls.
> > 
> > 
> > The problem here is all allocation functions are not in the RuntimeLibcalls list. All RuntimeLibcalls functions are preserved by LTO process (in general, unless for specific platform they are not available) because they can be produced by backend even if the bitcode object file don't reference them. There is no difference from this case, which `calloc` doesn't get referenced before optimization.
> 
> Well, I've done a brief investigation on this and looks like RuntimeLibcalls handling boils up to this snippet of code in lld
> 
> ```
>   if (!ctx.bitcodeFiles.empty())
>     for (auto *s : lto::LTO::getRuntimeLibcallSymbols())
>       handleLibcall(s);
> ```
> 
> The `handleLibcall` function check if IR symbol representing runtime library function is lazy, and adds its bitcode file to LTO input set if so. This doesn't really help much, because `calloc` (event if added to to RuntimeLibcalls set) is not a lazy symbol in my case. The problem is not that we don't add it but that we explicitly remove it in DCE. I'm starting to beleive that calloc is the unique case (I haven't found anything else of the sort).

It isn't lld that is doing the handling that preserves these symbols, it is LTO, specifically llvm/lib/Object/IRSymtab.cpp. See the use of RuntimeLibcalls.def here and where it is used to preserve symbols later in the file: https://github.com/llvm/llvm-project/blob/c38ae74b48c1cb8aedf384686eaa05815d366609/llvm/lib/Object/IRSymtab.cpp#L48-L57

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