Minor changes to reduce the copying needed for TargetLibraryInfoImpl when it's passed around by TargetLibraryAnalysis and TargetLibraryInfoWrapperPass, by using move whenever possible.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for the nice cleanup!
llvm/include/llvm/Analysis/TargetLibraryInfo.h | ||
---|---|---|
456 | Can T just be used here? TargetLibraryInfoImpl comes with a such constructor: TargetLibraryInfoImpl(const Triple &T) |
llvm/include/llvm/Analysis/TargetLibraryInfo.h | ||
---|---|---|
456 | Unlikely not. That is an explicit constructor and BaselineInfoImpl is an Optional object. |
Some parts of this are dependent on the patch that got reverted, but I have some other questions below about the changes in BackendUtil.cpp.
clang/lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
691 | These changes mean we now construct a new TLII multiple times (e.g. both when we add the TargetLibraryInfoWrapperPass to the MPM earlier and to the FPM here, rather that just copying. Is this actually faster? It seems like it would be slower overall. | |
llvm/lib/Analysis/TargetLibraryInfo.cpp | ||
586–587 | Woops, sorry, missed this one in the original review. | |
598 | This is missing copying of the VecLibDescs (looks like I missed this as well originally). | |
610 | Ditto. |
Thanks for quick review.. I will remove the changes dependent on the reverted change before commit.
clang/lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
691 | Oops, this one isn't intentional... changed it back. Though for other instances where TLII isn't reused, similar change turns extra copy into move. |
clang/lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
691 | I suppose you could std::move the TLII here to avoid this second copy. Do you know how much difference this patch makes on the compile time instruction count regressions seen with the original patch? It seems like it shouldn't be huge given that this is just during the pipeline setup for the module. But if it does explain the instruction count increases that's probably why it didn't regress the actual wall time measurements. |
Also, just a nit, because TLI is sometimes used to refer to the TargetLibraryInfo and occasionally to the TargetLibraryInfoImpl, and the latter is frequently referred to as TLII, could you change the description to say TLII or TLI Impl? Since this doesn't affect TargetLibraryInfo/TLI object copies.
clang/lib/CodeGen/BackendUtil.cpp | ||
---|---|---|
691 | Yeah, the 2nd use can be a move, though I'm inclined to not do that, as TLII isn't immediately out of scope yet. I didn't setup measurement for this. I was basically playing with some tests for sanity check just to make sure we're not doing things unexpectedly, e.g. we don't do per-function copies unexpectedly in TargetLibraryAnalysis::run. But other than a few extra copies on setup path, I didn't see anything unusual. Since the original patch can make any copies more expensive, I thought it's good to reduce that as I see it. | |
llvm/lib/Analysis/TargetLibraryInfo.cpp | ||
598 | Now I remembered why this was missed from my side, before my patch, VecLibDescs isn't copied here either, which seems like a bug? Same for the move one below. |
These changes mean we now construct a new TLII multiple times (e.g. both when we add the TargetLibraryInfoWrapperPass to the MPM earlier and to the FPM here, rather that just copying. Is this actually faster? It seems like it would be slower overall.