[PATCH] Add an LTO interface to parse metadata and extract linker options

[Yunzhong Gao]

================
Comment at: lib/CodeGen/TargetLoweringObjectFileImpl.cpp:407
@@ +406,3 @@
+/// option string. Returns StringRef() if the option does not specify a library.
+StringRef TargetLoweringObjectFileMachO::
+getDepLibFromLinkerOpt(StringRef LinkerOption) const {
----------------
Nick Lewycky wrote:
> Hmm. You want to stick a linker option parser inside codegen? Am I correct in understanding that COFF object files have linker flags in them?
> 
> Who fills in these linker options and dependent libraries? Is there any reason we couldn't hoist the linker option parsing into there?
Hi Nick,
> Am I correct in understanding that COFF object files have linker flags in them?

I assume you mean the COFF .drectve section.

The translation from IR's "Linker Options" named metadata to .drectve entries happens in
TargetLoweringObjectFileCOFF::emitModuleFlags() for COFF; and in
TargetLoweringObjectFileMachO::emitModuleFlags() for MachO. That is why I thought
TargetLoweringObjectFile{COFF,MachO} are good places to add these new functions. These
emitModuleFlags() routines do not appear to parse the linker options; they just output the
metadata strings as-is into the relevant directive sections.

The generation of these "Linker Options" named metadata happens in the clang
front end. For example, in cfe/trunk/lib/CodeGen/TargetInfo.cpp, look in
WinX86_32TargetCodeGenInfo::getDependentLibraryOption() and
TargetCodeGenInfo::getDependentLibraryOption(). The metadata strings received by the
backend are already "packaged" and I was trying to extract the library names back from there.

I would argue that by adding these routines to extract the library names, the results returned
by the LTO APIs could stay independent from how the linker options are packaged in the IR
metadata, although I should admit that the "/DEFAULTLIB:<library_name>" format used by
COFF has been around for quite a while and probably will not change.

================
Comment at: include/llvm-c/lto.h:201
@@ -201,2 +201,2 @@
 
 
----------------
kledzik at apple.com wrote:
> When you add new APIs to <llvm-c/lto.h> be sure to bump up LTO_API_VERSION, so that clients to do compiler configuration checks if the API exists.
Hi Nick,

I saw your discussion with Sean on the mailing list on this topic. I will bump up LTO_API_VERSION as you requested.

- Gao.


http://llvm-reviews.chandlerc.com/D2343