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

Yunzhong Gao Yunzhong_Gao at playstation.sony.com
Tue Jan 7 15:30:35 PST 2014


  On Sun, Jan 5, 2014 at 4:08 PM, "Duncan P. N. Exon Smith" <dexonsmith at apple.com> wrote:
  > Thanks for the explanation; I understand the use case now.
  > LGTM, once you’ve satisfied Reid’s comments about string lifetime.
  > Duncan
  > P.S. Sorry for the long delay!

  Hi Duncan, thanks again for the review! I only just came back from my vacation yesterday.

  On Thu, Dec 26, 2013 at 11:48 AM, "Reid Kleckner" <rnk at google.com> wrote:
  >  Interesting.  This is essentially exposing the info that we would have put into the
  > object file if we had generated one.
  >  ================
  > Comment at: include/llvm/Target/TargetLoweringObjectFile.h:60
  > @@ +59,3 @@
  > +  /// option string. Returns NULL if the option does not specify a library.
  > +  virtual const char *getDepLibFromLinkerOpt(StringRef LinkerOption) const {
  > +    return NULL;
  > ----------------
  > This should return a StringRef.
  >
  > ================
  > Comment at: lib/LTO/LTOModule.cpp:817
  > @@ +816,3 @@
  > +            getObjFileLowering().getDepLibFromLinkerOpt(Op))
  > +          _deplibs.push_back(DepLibName);
  > +        else if (!Op.empty())
  > ----------------
  > Now _deplibs and _linkeropts hold pointers into global metadata.  Is that OK?  Is that
  > metadata guaranteed to outlive LTOModule?  Might be better to copy here.

  I updated the patch to address both of these points.

  I would like to make a somewhat related observation since you mentioned string
  lifetime. If you take a look at the _symbols vector inside struct LTOModule, each
  NameAndAttributes entry includes both a pointer to the symbol name and a pointer
  to the symbol itself (as a GlobalValue). The symbol name referenced from
  NameAndAttributes is a copy with a StringSet. The symbol referenced from
  the same NameAndAttributes struct does not appear to be a copy; it is just part
  of the input llvm::Module. If the symbol is known to have a long lifetime, it
  would indicate that the copy of the symbol name is redundant. If the symbol's
  lifetime is not guaranteed, then maybe the reference to it could become invalidated
  at some point.

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

CHANGE SINCE LAST DIFF
  http://llvm-reviews.chandlerc.com/D2343?vs=6220&id=6379#toc

Files:
  tools/lto/lto.cpp
  tools/lto/lto.exports
  lib/LTO/LTOModule.cpp
  lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
  include/llvm/Target/TargetLoweringObjectFile.h
  include/llvm/LTO/LTOModule.h
  include/llvm-c/lto.h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D2343.4.patch
Type: text/x-patch
Size: 9735 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140107/b29e48e6/attachment.bin>


More information about the llvm-commits mailing list