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

[Daniel Dunbar]

Hi Tom,

Can you explain why lib/LTO needs to depend on all-targets? I'm not sure we
actually want this behavior, what we generally want is that clients can
pick the library and then pick the list of targets that get included. In
this case, I think the right thing that should happen is that both
tools/lto and llvm-lto depend on all targets and handle the target
initialization, whereas lib/LTO itself just relies on the targets already
having been initialized.

Is it possible to factor lib/LTO in that fashion?

 - Daniel


On Fri, Sep 20, 2013 at 11:59 PM, Tom Roeder <tmroeder at google.com> 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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130923/0913cc07/attachment.html>