Some compilers, including MSVC and Clang, allow linker options to be specified in source files. In the legacy LTO API, there is a getLinkerOpts() method that returns linker options for the bitcode module being processed. This change adds that method to the new API, so that the COFF linker can get the right linker options when using the new LTO API.
Details
Diff Detail
- Build Status
Buildable 3469 Build 3469: arc lint + arc unit
Event Timeline
lib/LTO/LTO.cpp | ||
---|---|---|
255 | We deliberately enable lazy loading of metadata here for performance reasons (debug metadata can be expensive to load). Eventually I think we will want to add the linker options to the bitcode symbol table (see pr27551), so that we will not need to load metadata at all in the COFF linker at symbol resolution time. In the meantime, I think it would be best to produce the linker options string on demand in getLinkerOpts after calling materializeMetadata. That way, linkers for other object formats don't pay the cost of loading metadata. Can you please also add a FIXME to add this to the symbol table? | |
275 | This loop (and the one below) can be a range for loop. | |
284 | It's probably best to emit the /export flags from here as well, see TargetLoweringObjectFileCOFF::emitLinkerFlagsForGlobal. |
lib/LTO/LTO.cpp | ||
---|---|---|
255 | I agree. I'll add that technically if it is really important for you to get cheaply this you could hook it up to the MD lazy-loading scheme to load this without loading all the MDs. |
Thanks for the comments! I've changed it so that metadata is only materialized if someone actually calls getLinkerOpts, and converted the loops to use ranges.
lib/LTO/LTO.cpp | ||
---|---|---|
309 | This will lead to a use after free I think. |
lib/LTO/LTO.cpp | ||
---|---|---|
309 | Sorry, no, I didn't notice that this was a field. I would just remove the field and make this return a std::string. |
lib/LTO/LTO.cpp | ||
---|---|---|
309 | Hmm, I don't think so. The StringRef here is a reference to LinkerOpts, which is a std::string stored on the InputFile. So that should still be valid after this function returns. LOS.str() just calls flush() on the ostream and returns the StringRef. I think this is ok. |
Made getLinkerOpts() also sythesize /export flags for symbols with dllexport linkage, as @pcc suggested
lib/CodeGen/TargetLoweringObjectFileImpl.cpp | ||
---|---|---|
922 ↗ | (On Diff #86749) | I moved this into a separate function so that we don't have to do the whole TargetTriple, TargetRegistry, SubtargetFeatures, etc. etc. dance to create a TargetLOweringObjectFileImpl, just to call one method that doesn't need all that information. |
Removed braces, friend declaration, and defensive programming.
Iterate ModuleSymbolTable instead of using symbol_iterator.
We deliberately enable lazy loading of metadata here for performance reasons (debug metadata can be expensive to load).
Eventually I think we will want to add the linker options to the bitcode symbol table (see pr27551), so that we will not need to load metadata at all in the COFF linker at symbol resolution time.
In the meantime, I think it would be best to produce the linker options string on demand in getLinkerOpts after calling materializeMetadata. That way, linkers for other object formats don't pay the cost of loading metadata. Can you please also add a FIXME to add this to the symbol table?