[llvm] r191042 - Fix LTO handling of module-level assembly (PR14152).

Peter Collingbourne peter at pcc.me.uk
Mon Sep 23 11:07:52 PDT 2013


Hi Daniel,

Would you be able to review the llvm-build parts of Tom's patch, please?

Thanks,
Peter

On Fri, Sep 20, 2013 at 11:59:27PM -0700, Tom Roeder wrote:
> I've written a patch now (in consultation with Peter) that does
> exactly this: tools/llvm-lto is split into a lib/LTO component and a
> tools/llvm-lto component, and tools/llvm-lto is written to depend only
> on lib/LTO (and not tools/lto, hence not libLTO.so). This should solve
> the problems with the freebsd build and additionally be a better
> factorization of the code.
> 
> However, this design led to an interesting problem: lib/LTO needs to
> depend on all-targets, and having a library that depends on
> all-targets wasn't supported by the existing llvm-build scripts (the
> required_libraries of all-targets came up with empty
> required_libraries of their own). So, I've modified
> llvm-build/llvmbuild/main.py to fill out these implicit dependencies,
> using the information from the add_to_library_groups entries in the
> LLVMBuild.txt files.
> 
> I've run clean builds with cmake/ninja, cmake/make, and Makefile and
> run check successfully on each of them (on Linux). And I've built
> LLVMgold.so against the Makefile version and tested it on a simple
> test file (the test case from this patch).
> 
> However, my patch as it stands combines svn mv operations with edits
> on the moved files, so it's far more verbose than necessary and loses
> some of the history information (by not exactly capturing the move
> information). Would you like me to formulate this as two patches: a
> move followed by edits?
> 
> Please let me know what you think.
> 
> Thanks,
> 
> Tom
> 
> On Fri, Sep 20, 2013 at 12:50 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
> > On Fri, Sep 20, 2013 at 12:25:17PM -0700, Tom Roeder wrote:
> >> Actually, it looks like libLTO.so simply isn't getting built or found here
> >> and that's why the test is failing.
> >
> > Hm?  The compile log:
> > http://lab.llvm.org:8011/builders/clang-X86_64-freebsd/builds/10381/steps/compile/logs/stdio
> > seems to indicate that libLTO is being built.
> >
> > I suspect that the problem is that the rpath isn't being embedded
> > in the llvm-lto binary on FreeBSD in the correct way, though I can't
> > tell for sure, since I don't have access to a FreeBSD machine.
> >
> > I'm beginning to think that the right way to solve this problem is
> > to move LTOCodeGenerator.cpp and LTOModule.cpp in tools/lto into
> > a new component 'lto' in lib/LTO and have tools/lto (which would
> > then contain only the C interface) and tools/llvm-lto (and maybe
> > tools/gold in the future) depend on the lto component.  That way,
> > the LTO support library is no different to any other component of
> > LLVM and is less likely to cause problems across platforms.
> >
> > Thanks,
> > --
> > Peter



-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib_lto.patch
Type: text/x-diff
Size: 134157 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130923/4042f79f/attachment.patch>


More information about the llvm-commits mailing list