[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