================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
