keeping as much as possible internal/private is
known to help the optimizer. Let's try to benefit from
this in ThinLTO.
Note: this is early work, but is enough to build clang (and
all the LLVM tools). I still need to write some lit-tests...
Details
Diff Detail
Event Timeline
lib/LTO/ThinLTOCodeGenerator.cpp | ||
---|---|---|
309 | It seems there is already some support in libLTO for detecting these, see the call to LTOModule::addAsmGlobalSymbolUndef(). Can that be leveraged here? What is the difference between what is being detected by these two cases? If it needs to use the IRObject method, can that functionality be refactored into a method in libObject that is callable from here? It seems like it could return the AsmSymbols vector and you could just iterate that here looking for a Key that is BasicSymbolRef::SF_Undefined in the returned pair, and is !TheModule.getNamedValue(Key). Using a refactored common routine would make it easier to do similar optimizations in the gold and lld cases as well. | |
378 | Missing comment | |
386 | I guess the assumption is that there is nothing to export if there is nothing to preserve? Should there be an assertion here that ExportList is empty? | |
406 | doxygen style /// comment (here and with other added functions) | |
420 | Why not add these to the PreservedGV set? | |
671 | Should this be a FIXME? |
Address comments
lib/LTO/ThinLTOCodeGenerator.cpp | ||
---|---|---|
386 | No this is completely independent: if the client didn't supply anything to preserve, we don't internalize at all. Changed the comment. | |
406 | I think it is relevant only for public API. These are static function so they won't show up in doxygen: http://llvm.org/doxygen/ThinLTOCodeGenerator_8cpp.html | |
420 | PreservedGV drives the internalizer, this is possibly driving other places in LLVM I think, like GlobalDCE for example. | |
671 | added |
It seems there is already some support in libLTO for detecting these, see the call to LTOModule::addAsmGlobalSymbolUndef(). Can that be leveraged here? What is the difference between what is being detected by these two cases?
If it needs to use the IRObject method, can that functionality be refactored into a method in libObject that is callable from here? It seems like it could return the AsmSymbols vector and you could just iterate that here looking for a Key that is BasicSymbolRef::SF_Undefined in the returned pair, and is !TheModule.getNamedValue(Key). Using a refactored common routine would make it easier to do similar optimizations in the gold and lld cases as well.