similar to: CMake option to disable LTO?

On Thu, Mar 17, 2016 at 11:45 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Thu, Mar 17, 2016 at 10:05 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: >> [ brutal-snip ] >> ... >>> [ TODO#S: Before doing a 2nd build (and in a 3rd run using more >>>

Hello everyone, I'm trying to compile LLVM and Clang into LLVM IR with debug info. I know that clang++ -g2 -S -emit-llvm <filename> does this, but I'm unfamiliar with CMake. I tried changing CMAKE_CXX_FLAGS in CMakeCache.txt to "clang++ -g2 -S -emit-llvm," "-g2 -S -emit-llvm," and "-emit-llvm," but everything I tried resulted in a failed build, and/or

Hi Tomas, > On 4/23/19 2:59 PM, Thomas K?nig wrote: >> Hi, >> >> there can be an issue with recent gcc where the system-installed "ar" >> and "ranlib" commands cannot handle LTO binaries.? On compilation, this >> manifests itself with error messages claiming that they need extra >> plugins. > Thanks for the report. What was the

On Mon, Mar 14, 2016 at 5:30 PM, Chris Bieneman <cbieneman at apple.com> wrote: [ brutal-snip ] ... > [ TODO#S: Before doing a 2nd build (and in a 3rd run using more > optimized binaries) ] > > How do I anable LTO via CMAKE? > > > LLVM_ENALBLE_LTO=On > [ v4 of my build-script attached ] Hi Chris, thanks for the response! That seems to work (see below). $ cd

On Tue, Dec 20, 2016 at 5:05 PM, Teresa Johnson <tejohnson at google.com> wrote: > Hi Carsten, > > A few responses below, but first, can you get the link command for > lldb.so.3.9.1? Last time it was the lldb.so build that was using > ld.bfd with the gold plugin which was exposing this issue. Where would I find it in an otherwise already terminated process? > On Tue, Dec

​Hi again, Teresa. Looks like I had forgotten to report back with success when finally building 3.9.0 in ThinLTO linker mode back in October. Sorry about that and thanks for helping me out. I know how important it is to get success reports as well, as a developer myself, so sorry again :(. While that worked back then, last weekend I tried to build 3.9.1 using 3.9.0 as installed from Arch Linux

On Mon, Oct 3, 2016 at 10:54 PM, Teresa Johnson <tejohnson at google.com> wrote: > > Aha - finally reproduced! The difference is using ld.bfd not > ld.gold. With that I get the same failure (using 3.9 to build 3.9 > sources): Thanks a lot! [...] > I am not sure what the official support story is for LLVMgold.so and > ld.bfd. As mentioned earlier, the LLVM site indicates

Adding a couple of lld folks. I helped Shishir debug this, the link line looked like: /home/sjessu/build/bin/clang -O0 -flto -o jcstest jcstest.o ./.libs/libjpeg.a and the issue was that libjpeg.a was created with the system ar instead of llvm-ar. It worked when recreating libjpeg.a with llvm-ar. I noticed that the lld code has some special handling for the case when there is a missing

Hi Carsten, A few responses below, but first, can you get the link command for lldb.so.3.9.1? Last time it was the lldb.so build that was using ld.bfd with the gold plugin which was exposing this issue. On Tue, Dec 20, 2016 at 5:49 AM, Carsten Mattner <carstenmattner at gmail.com> wrote: > ​Hi again, Teresa. > > Looks like I had forgotten to report back with success > when

If I've configured a Release build, build it and then go back and re-run cmake with -DCMAKE_BUILD_TYPE=Debug (and nothing else changed), almost nothing gets rebuilt when I try to build. Is this expected? I know I can edit CMakeCache.txt directly and trigger an essentially full rebuild. -David

On my computer it is pain in the a** to build LLVM/clang with LLVM LTO on using cmake. I have to add -k to the make command and run ranlib from time to time. Anyway to fix this? OS: Ubuntu 13.04 amd64 LLVM Version: LLVM 3.4 svn HEAD. By the way, the resulting binary built with flags -Ofast -flto runs blazingly fast. I can compile entire GNUstep libraries in under a minute without parallelism.

ChanMaxthon <xcvista at me.com> writes: > On my computer it is pain in the a** to build LLVM/clang with LLVM LTO > on using cmake. I have to add -k to the make command and run ranlib > from time to time. Anyway to fix this? To fix what? Please file a bug report with all relevant info, starting with a complete description of the problem ;-)

> 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

On Mon, Aug 31, 2015 at 9:53 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > Having it off by default makes sense to me. We just need an easy way of > enabling it from the clang driver. > Not sure I follow? Generally LTO inputs are going to be "user provided" (in the sense that they're not produced immediately prior by the same process - or you'd have

Now I have -DLLVM_INCLUDE_EXAMPLES:BOOL=OFF but Kaleidoscope is still there and selected for build (-G "Visual Studio 9 2008") -Jochen

The verifier takes ~5% of link time when using LTO. I think we should add a `-disable-llvm-verifier` option to the LTO plugins, and change the clang driver to pass the option through in release builds. In asserts builds, the clang driver would not pass the option. This would match the way the driver passes -disable-llvm-verifier to -cc1. Everyone on board?

On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola <llvm-dev at lists.llvm.org> wrote: > > > Not sure I follow? Generally LTO inputs are going to be "user provided" > (in the sense that they're not produced immediately prior by the same > process - or you'd have just produced a single Module in the first place, I > would imagine) so changing the default

On Mon, Aug 31, 2015 at 11:40 AM Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Aug-31, at 10:42, Reid Kleckner <rnk at google.com> wrote: > > > > On Mon, Aug 31, 2015 at 10:12 AM, Rafael Espíndola < > llvm-dev at lists.llvm.org> wrote: > > > > > Not sure I follow? Generally LTO inputs are going to

> 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

Hi Nico, Hans, Takumi, I made it to the bottom of the issue. Turns out that CMAKE_C_FLAGS=-m64 CMAKE_CXX_FLAGS=-m64 CMAKE_EXE_LINKER_FLAGS=/machine:x64 is enough to do a 64-bit build correctly with a 32-bit clang-cl (i.e. one that targets 32-bit by default). Hooray! The missing piece that I had to track down is why I would see `deps = msvc` stuff spewing onto my terminal, rather than consumed