search for: liblto

...t;>>>>>> *sigh* Reasons to hate the driver interface again... > >>>>>>>> > >>>>>>>> I guess this is ok. Could possibly add it to the existing terrible > >>>>>>> "enable this pass" interface on liblto as well. > >>>>>>> > >>>>>>> The linker doesn't know whether clang was built with asserts, though. > >>>>>>> > >>>>>>> We could just make it implicit: move the decision to libLTO itself. Given &gt...

...>>>> > >> >>>> *sigh* Reasons to hate the driver interface again... > >> >>>> > >> >>>> I guess this is ok. Could possibly add it to the existing terrible > >> >>> "enable this pass" interface on liblto as well. > >> >>> > >> >>> The linker doesn't know whether clang was built with asserts, though. > >> >>> > >> >>> We could just make it implicit: move the decision to libLTO itself. Given > >> >>> that c...

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>

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 expos...

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 (32 vs. 64 bit) or if the bitcode format chan...

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 ../../Developer/usr/lib/libLT...

...> sense? >> >>>> >> >>>> *sigh* Reasons to hate the driver interface again... >> >>>> >> >>>> I guess this is ok. Could possibly add it to the existing terrible >> >>> "enable this pass" interface on liblto as well. >> >>> >> >>> The linker doesn't know whether clang was built with asserts, though. >> >>> >> >>> We could just make it implicit: move the decision to libLTO itself. >> Given >> >>> that clang and libLTO.d...

...data race (pid=17192) Atomic write of size 4 at 0x0001113619e8 by thread T13: #0 __tsan_atomic32_compare_exchange_val <null>:568340296 (libclang_rt.tsan_osx_dynamic.dylib+0x00000003e7aa) #1 llvm::sys::CompareAndSwap(unsigned int volatile*, unsigned int, unsigned int) Atomic.cpp:52 (libLTO.dylib+0x000000511914) #2 llvm::initializeSimpleInlinerPass(llvm::PassRegistry&) InlineSimple.cpp:82 (libLTO.dylib+0x000000ab2b55) #3 (anonymous namespace)::SimpleInliner::SimpleInliner() InlineSimple.cpp:50 (libLTO.dylib+0x000000ab2e8e) #4 (anonymous namespace)::SimpleInliner::Simpl...

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

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...

Hello all, I'm a research assistant at the University of Wisconsin and we're trying to come up with a general way to run our whole program analysis over programs that may use different methods to perform the build. I saw some discussion that liblto could be used for this (and safecode successfully did it) for llvm 2.6 - 3.0, but that doesn't seem to be working the same way with llvm 3.1+. Is it still possible to install our pass into liblto directly anymore? Is there perhaps a better way to have the linker intercept and run our analysis...

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 suppor...

...ke > >>>> sense? > >>>> > >>>> *sigh* Reasons to hate the driver interface again... > >>>> > >>>> I guess this is ok. Could possibly add it to the existing terrible > >>> "enable this pass" interface on liblto as well. > >>> > >>> The linker doesn't know whether clang was built with asserts, though. > >>> > >>> We could just make it implicit: move the decision to libLTO itself. > Given > >>> that clang and libLTO.dylib are different execu...

...39;m thinking `-mllvm -disable-verify`. Make > > > sense? > > > > > > *sigh* Reasons to hate the driver interface again... > > > > > > I guess this is ok. Could possibly add it to the existing terrible > > "enable this pass" interface on liblto as well. > > > > The linker doesn't know whether clang was built with asserts, though. > > > > We could just make it implicit: move the decision to libLTO itself. Given > > that clang and libLTO.dylib are different executables anyway -- and you > > might be...

...S=macos RC_ARCHS="i386" TARGETS="i386 x86_64" SRCROOT=`pwd` OBJROOT=`pwd`/build/obj DSTROOT=`pwd`/build/dst SYMROOT=`pwd`/build/sym 3. Replace old llvm-gcc with new one # rm -rf /Developer/usr/llvm-gcc-4.2 # ditto build/dst / ------ rest only once ------- 4. Fix libLTOs # rm /Developer/usr/lib/libLTO.dylib # ln -sf /Developer/usr/local/lib/libLTO.dylib /Developer/usr/lib/ libLTO.dylib # rm /usr/lib/libLTO.dylib # ln -sf /Developer/usr/local/lib/libLTO.dylib /usr/lib/ libLTO.dylib 5. Fix /Developer/SDKs/MacOSX10.5.sdk/Developer/usr # c...

Dear LLVMers, I'm currently working on creating an alternate libLTO.so that will run some whole-program analysis and transforms of mine during the final linking of an executable. The idea is for it to link all of the bitcode files together, run the regular LTO passes, and then run my passes. For Linux, I should be able to get the Gold linker to load my libLTO...

...disable-llvm-verifier` to ld64 > is redundant... so I'm thinking `-mllvm -disable-verify`. Make > sense? > > *sigh* Reasons to hate the driver interface again... > > I guess this is ok. Could possibly add it to the existing terrible "enable this pass" interface on liblto as well. The linker doesn't know whether clang was built with asserts, though. We could just make it implicit: move the decision to libLTO itself. Given that clang and libLTO.dylib are different executables anyway -- and you might be interposing an asserts libLTO.dylib to use with an instal...

On Dec 4, 2009, at 2:49 PM, John Criswell wrote: >> If you are building llvm-gcc yourself, try, in this order: >> 1) sudo ln -s ../../Developer/usr/lib/libLTO.dylib /usr/lib/ >> libLTO.dylib >> >> 2) If you still get errors, try installing the libLTO.dylib from >> your LLVM build into /Developer/usr/lib. Make sure that if you're >> on a 64-bit machine, you built llvm for x86_64-apple-darwin10 >> (which shoul...

...then Diego's > instructions are fine. > > If, however, you want to do inter-procedural optimization or whole > program analysis, then there's additional things you need to do. > > If you just want to use LLVM's link-time optimizations, you will need > to use the libLTO library with your linker. Your linker, in turn, > must be able to support plugins (like the gold linker, for example). > For directions on how to set up libLTO, see > http://llvm.org/docs/LinkTimeOptimization.html and > http://llvm.org/docs/GoldPlugin.html. > > If you want t...

...he linker to do linking, but the linker fails because the object files are LLVM bitcode files. This is obviously a problem for link-time optimization, so what the LLVM Developers decided to do was to teach the linker how to link LLVM bitcode files together. They built a dynamic library called libLTO that links LLVM bitcode files together, can do interprocedural optimization on them, and generate native code from them. The gold linker on Linux and the XCode linker on Mac OS X can load this dynamic library; once it does, it can link and optimize LLVM bitcode files, allowing link-time optim...