Symbols that have dllexport storage class need to be preserved by link-time optimization. This change allows users of the LTO API to determine if a symbol has dllexport storage. This will be used in an upcoming refactor of the COFF linker's LTO code.
Diff Detail
- Build Status
Buildable 3210 Build 3210: arc lint + arc unit
Event Timeline
Is this necessary? As far as I know, the effect of dllexport is to cause a "/export" linker directive to be emitted. I was imagining that you would port LTOModule::parseMetadata to the new LTO API, then you would get dllexport support "for free".
@pcc, dll.test fails without this. It generates an object file which has this about exportfn3:
define dllexport void @exportfn3() { ret void }
It does not define any directives, so without looking for dllexport, the symbol ends up being optimized away, and the test fails.
I think we can probably get by without having hasDLLExportStorageClass here if we're willing to separately look at the bitcode file to find dllexported symbols, but that seems more expensive. The way this is implemented is the analogue of ELF's canBeOmittedFromSymbolTable().
@ruiu and I were wondering if we can unify the check for dllexport with the one ELF uses. It seems it would be useful to have a generic concept of a symbol that may not be used internally, but must be preserved because it's required for external objects to link with. Perhaps canBeOmittedFromSymbolTable() is exactly that, or perhaps we can make it into that. I'll do some more digging.
canBeOmittedFromSymbolTable() is very much an ELF/Mach-O specific feature (and an optimization), so I don't think it's really applicable here. What I was suggesting was that you could teach the function you add to InputFile that returns a list of linker directives to also emit /export directives, then for dll.test that function would return something like /export:exportfn3.
We don't need this change anymore. D29365 implements a different way to get the functionality we need.