similar to: [LLVMdev] Gold plugin: emit LLVM after LTO?

> > > I often use the gold plugin's also-emit-llvm option to verify the final > LLVM bitcode of a program. However, I realized that the gold plugin generates >> the >> bitcode file before running LTO optimizations, such that the changes >> performed >> by LTO are not reflected in the bitcode file. >> >> What is the reason for this behavior?

Hi Jonas, On 04/06/13 10:23, Jonas Wagner wrote: > Hi, > > I often use the gold plugin's also-emit-llvm option to verify the final LLVM > bitcode of a program. However, I realized that the gold plugin generates the > bitcode file before running LTO optimizations, such that the changes performed > by LTO are not reflected in the bitcode file. > > What is the reason for

The Apple ld (shipped with Xcode, open-source) saves the 3 files if -save-temps is applied: - xxx.lto.bc : the merged bit-code before IPA - xxx.lto.opt.bc: the optimized bit-code of the *.lto.bc - xxx.lto.o : the object file of xxx.lto.bc I think it is better way to go, often time we need IR both after and after the transformation. On 6/4/13 3:37 AM, Jonas Wagner wrote: > >

On 4 June 2013 13:36, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > The Apple ld (shipped with Xcode, open-source) saves the 3 files if > -save-temps is applied: > - xxx.lto.bc : the merged bit-code before IPA > - xxx.lto.opt.bc: the optimized bit-code of the *.lto.bc > - xxx.lto.o : the object file of xxx.lto.bc > > I think it is better way to go, often time we

> The Apple ld (shipped with Xcode, open-source) saves the 3 files if > > -save-temps is applied: > > - xxx.lto.bc : the merged bit-code before IPA > > - xxx.lto.opt.bc: the optimized bit-code of the *.lto.bc > > - xxx.lto.o : the object file of xxx.lto.bc > > > > I think it is better way to go, often time we need IR both after and > after >

Hi, I was trying to build clang (svn head version) using clang-3.1 version. I am building a debug version using LTO/gold plugin. It is crashing with signal 9 when trying to link the bitcode files to build the executable. I am not sure, if this is a bug or just a memory issue. Has anyone done anything similar or noticed similar behavior? Any help would be welcome. Thanks, Swarup.

Two suggestions: - Use a 64-bit operating system. - You could disable the LTO optimizations by commenting out a few lines in tools/lto/LTOCodeGenerator.cpp to determine if the problem is a pass or with LTO itself. On Wed, Oct 17, 2012 at 10:38 AM, Sahoo, Swarup Kumar <ssahoo2 at illinois.edu> wrote: > Hi, > > I was trying to build clang (svn head version) using clang-3.1

Hi, unfortunately, my build somehow hangs when linking clang binary and my system is in an unusable state. My toolchain is clang-3.8, gold-1.11 and LLVMgold.so from binutils v2.26.1 (both selfmade) and LTO-flag is enabled. My buildsystem uses cmake-3.6.0 and ninja-1.7.1 (both prebuilt). I have 52 last steps left in my 3rd build. My Linux-kernel is v3.13.0-92 from official Ubuntu repositories.

We've found an error during the use of LTO that appears to happen only during the use of the gold linker. We essentially have a file which is compiled *without* LTO: f1() { h1(); } And a second file that is compiled/linked *with* LTO: f2() { f1(); h1(); } This second file has the function h1() inlined during LTO. The resulting executable fails because the symbol for h1

Hi, I'm using clang frontend. I'm interested in some particular hot loop in my code and I emit a report from vectorizer optimizations passes. I receive nice output if passing -Rpass* flags as long as I'm building without LTO? But with -flto it just prints nothing. Is there a way to emit opt reports when using LTO? For now I can only approximate about whether my the loop will be

So you see the issue as well in ARM? When doing a objdump -D weakMainO1.exe | grep -A 10 "<_ZN1C13caller_methodEv>:" I see: 00008b88 <_ZN1C13caller_methodEv>: 8b88: e92d4800 push {fp, lr} 8b8c: e1a0b00d mov fp, sp 8b90: e24dd008 sub sp, sp, #8 8b94: e58d0004 str r0, [sp, #4] 8b98: e59d0004 ldr r0, [sp, #4] 8b9c: ebffdd17 bl 0

I have gold from cvs, and llvm-gcc/llvm from svn. My platform is Ubuntu 9.04 x86_64. I've configured llvm-gcc with "--enable-multilib". When compiling the LTO example from http://llvm.org/docs/LinkTimeOptimization.html I have no problems with 64-bit compilation, but get the following with -m32. luked at node:~/tests/lto$ make USE32=1 llvm-gcc -m32 -c -o main.o main.c llvm-gcc

How big is your project? LTO eats RAM even faster than chrome. For example linking clang with LTO could take 16GB of ram. Have you tried using LTO on your project on that machine, or is it your first time? Piotr On Sat, Jul 23, 2016 at 2:42 AM, Sedat Dilek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jul 21, 2016 at 12:01 PM, Sedat Dilek <sedat.dilek at

While doing research using the LLVM link time optimizer, we discovered a bug in the LTO plugin. After running the passes, the plugin tries to tell gold about 0 symbols produced from a bitcode file, indexing an empty vector in the expression &I->syms[0]. We're not completely sure if this is the best patch or if it is a symptom of a larger problem, but it worked for us. When we found

Glad to hear you can reproduce it. What I don't know is if this is a linker issue or an LLVM issue. -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Friday, May 30, 2014 3:58 PM To: Daniel Stewart Cc: LLVM Developers Mailing List Subject: Re: Error with Gold Linker during LTO Sorry, I had understood that the linker was crashing, not the

On 30 August 2010 12:43, Luke Dalessandro <luked at cs.rochester.edu> wrote: > I have gold from cvs, and llvm-gcc/llvm from svn. My platform is > Ubuntu 9.04 x86_64. I've configured llvm-gcc with "--enable-multilib". > > When compiling the LTO example from > http://llvm.org/docs/LinkTimeOptimization.html I have no problems with > 64-bit compilation, but get

> On Jul 23, 2016, at 1:53 PM, Sedat Dilek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Jul 23, 2016 at 7:48 PM, Piotr Padlewski <prazek at google.com <mailto:prazek at google.com>> wrote: >> How big is your project? >> LTO eats RAM even faster than chrome. For example linking clang with LTO >>

Hi, It was suggested that I post my question regarding a LLVM 3.4 performance regression to this mailing list, rather than stackoverflow. So here is the link: https://stackoverflow.com/questions/22902034/llvm-3-4-performance-regressed Thanks :) Jens -- Jens Tröger http://savage.light-speed.de/

Ah! Okay. A quick test of llvm-lto gets an error: llvm-lto: error adding file 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used

Hi, In my work applying -flto to Chrome, I need to set some names to be skipped by the InternalizePass; otherwise, the linking stage fails (i.e., when building the chrome binary). In the past, I had a tiny patch that I hadn't submitted to LLVM: it was something like: Index: Internalize.cpp =================================================================== --- Internalize.cpp (revision