[PATCH] Add an LTO interface to parse metadata and extract linker options
Nick Lewycky
nlewycky at google.com
Tue Jan 14 15:54:30 PST 2014
The libLTO API here is fine.
I'm surprised to see the return of dependent libraries in modules. For history,
see:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157053.html
Secondly, I don't think this needs to be metadata. It doesn't need to hold weak
references to IR values. I *think* I'd rather they were first-class properties
of llvm::Module? This would require some general agreement on llvm-dev.
A Module more or less corresponds to a single .o file, which makes storing
properties like linker flags a bit unusual. (This is true regardless of whether
you make it a first class property or use named metadata.) Could you explain
why it belongs here?
================
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 {
----------------
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?
http://llvm-reviews.chandlerc.com/D2343
More information about the llvm-commits
mailing list