similar to: Why is LTO built as a shared lib?

+ OptLevel = opt[1] - '0'; Please check and reject things like -OX at least in the gold plugin. Can you add a test showing that * createLowerBitSetsPass is run at -O0 * the addLateLTOOptimizationPasses passes are run at -O1, but not -O0 I think the patch is fine otherwise, but wait for a review from someone on the ld64 side (Duncan, Manman or Bob for example). Thanks, Rafael

On Fri, Sep 04, 2015 at 11:13:43AM -0700, Mehdi Amini wrote: > > > On Sep 4, 2015, at 11:03 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > On Fri, Sep 4, 2015 at 12:48 AM Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Sep 4, 2015, at 12:22 AM, Eric Christopher <echristo

On Fri, Sep 4, 2015 at 12:48 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Sep 4, 2015, at 12:22 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > >> Hi, >> >> > On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev < >>

For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael

> On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > > On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > > Yep. This is where I was going :) > > Glad I found consensus, but I want to

On Thu, Sep 3, 2015 at 11:45 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi, > > > On Sep 2, 2015, at 7:31 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > >> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > >>

On Fri, Sep 04, 2015 at 03:11:39PM -0700, Mehdi Amini wrote: > > > On Sep 4, 2015, at 11:38 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Fri, Sep 04, 2015 at 11:13:43AM -0700, Mehdi Amini wrote: > >> > >>> On Sep 4, 2015, at 11:03 AM, Eric Christopher <echristo at gmail.com> wrote: > >>> > >>> >

AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this

On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: > On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < > dexonsmith at apple.com> wrote: > > > > > > On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > > > > > On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith

> On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote: > Yep. This is where I was going :) Glad I found consensus, but I want to double-check that this makes sense to add to the driver. I didn't quite think through the implications myself. Since the driver doesn't know if there's any bitcode, or if LTO is going to be invoked, it seems like I'll

I'm confused. libLTO takes bitcode files as input and creates a native object file as output. Why would libLTO create bitcode as output? If so, you're changing the existing API contract. Or are you creating an out-of-band bitcode file, in which case the linker would never see it. ld doesn't have bitcode support, it has libLTO support, and libLTO is what processes the bitcode.

Shantonu Sen wrote: > Are you building llvm-gcc yourself? If so, what version? > > Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. > Thanks. A bitcode format mismatch was the problem. I'm not sure if the problem stems from the fact that the bitcode was generated for the wrong architecture

On Thu, Mar 19, 2015 at 11:12 AM Rafael Espíndola < rafael.espindola at gmail.com> wrote: > Having the analogous of -O0/-O1/-O2/-O3 for the LTO pipeline makes > sense I think. > > I agree that something along option number 2 is probably the best. > Some questions: > > * Should "clang -O3 foo.o -o foo" use LTO with -O3? > * Should "clang foo.o -o

I am wondering how the following issue was handled for libLTO? We have a working patch to implement the FSF gcc LTO on darwin which now passes all of the liblto testsuite but are seeing linker issues with larger programs like aermod... as -arch x86_64 -force_cpusubtype_ALL -o aermod.o aermod.s /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.6.3 -weak_reference_mismatches

On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On 2015-Sep-02, at 19:31, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote: >>> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith < >>> dexonsmith at

Are you building llvm-gcc yourself? If so, what version? Xcode releases include an older llvm-gcc and libLTO.dylib, which may not understand bitcode generated by newer self-built compilers. If you are only using llvm-gcc from the Xcode tools release, use the driver from: /Developer/usr/bin/llvm-gcc-4.2 If you are building llvm-gcc yourself, try, in this order: 1) sudo ln -s

Hello, Is there any CMake variable available to build LLVM libs as static libraries. I found one -DLIBCLANG_BUILD_STATIC=ON but what if I want libLTO.a instead of libLTO.dylib ? *Vivek Pandya* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151214/1e03efc9/attachment.html>

> On Sep 16, 2015, at 9:45 AM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 16, 2015 at 7:47 AM, Teresa Johnson <tejohnson at google.com> wrote: >> On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>>> On 2015-Sep-02, at 19:31, Peter

This is probably a problem with having too many sections. There are a few places where mach-o has a limit on the number of sections. For instance the n_sect field of the nlist record is one byte. So any symbol in a section past the 255th section wraps around and shows up with the wrong n_sect number. -Nick On Apr 29, 2010, at 6:19 AM, Jack Howarth wrote: > I am wondering how the

Hi all, libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO). I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others