[clang] [lld] [llvm] [LTO][LLD] Prevent invalid LTO libfunc transforms (PR #164916)

[Matt Arsenault via cfe-commits]

================
@@ -75,12 +76,14 @@ struct Builder {
   Builder(SmallVector<char, 0> &Symtab, StringTableBuilder &StrtabBuilder,
           BumpPtrAllocator &Alloc, const Triple &TT)
       : Symtab(Symtab), StrtabBuilder(StrtabBuilder), Saver(Alloc), TT(TT),
-        Libcalls(TT) {}
+        TLII(TT), TLI(TLII), Libcalls(TT) {}
 
   DenseMap<const Comdat *, int> ComdatMap;
   Mangler Mang;
   const Triple &TT;
 
+  TargetLibraryInfoImpl TLII;
+  TargetLibraryInfo TLI;
   // FIXME: This shouldn't be here.
   RTLIB::RuntimeLibcallsInfo Libcalls;
----------------
arsenm wrote:

This is kind of moving in the opposite and the same direction as I've been trying to go with RuntimeLibcallsInfo at the same time. 

I think that long term RuntimeLibcallsInfo and TargetLibraryInfo need to be merged into one analysis. I think the path of least resistance is to turn RuntimeLibcallsInfo into TargetLibraryInfo, which is most of my work in the last year has been towards. This is starting from the other direction, and treating TargetLibraryInfo more like RuntimeLibcallsInfo (most of my patches are adding RuntimeLibcallsInfo usage in places currently using TargetLibraryInfo, this is doing the opposite).

The fused analysis should separately be able to express which functions are callable, and which are known to have special semantics. That's the approximate distinction between the two today. The problem is the middle end optimizations consider TargetLibraryInfo only, and the backend mostly considers RuntimeLibcallsInfo. 

If we're going in this direction for this one particular area, the FIXME there applies to both of these (i.e., the future fused version). This specifically refers to turning the availability into a module analysis, not having a locally computed set of functions from the triple.

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