similar to: [LLVMdev] llvm-link deprecated in favor of gold plugin?

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

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

> 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

In LTOCodeGenerator.cpp there are some options related to optimization remarks. On MacOS, I can pass in this option to enable them: -Wl,-mllvm,-lto-pass-remarks-output=remarks But on Linux using 2.29.1 binutils version of gold, I try this alternative: -Wl,--plugin-opt,-lto-pass-remarks-output=remarks But I get this error message: LLVMgold: Unknown command line argument

The end goal is the ability to turn on thin-lto as easy as turning optimizations like -O2 or -O3 -- we want friendliness, very much :) David On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com> wrote: > I'm not sure this is a particularly great assumption to make. We have to > support a lot of different build systems and tools and concentrating on >

Hi: &nbsp; &nbsp; I want to learn&nbsp; how LTO and thinLTO work? But I'm confused how lld invoked either library. How can I find it in lld. Should i be familiar with lld source code? And i also think if there is some easy test case and with step-by- step debugging or some log messages can help me learn this? Is there some method can do stuff like this? &nbsp; Thank you very

The design objective is to make thinLTO mostly transparent to binutil tools to enable easy integration with any build system in the wild. 'Pass-through' mode with 'ld -r' instead of the partial LTO mode is another reason. David On Thu, May 14, 2015 at 7:30 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Thu, May 14, 2015 at 7:22 AM, Eric Christopher

So, what Alex is saying is that we have these tools as well and they understand bitcode just fine, as well as every object format - not just ELF. :) -eric On Thu, May 14, 2015, 6:55 AM Teresa Johnson <tejohnson at google.com> wrote: > On Wed, May 13, 2015 at 11:23 PM, Xinliang David Li > <xinliangli at gmail.com> wrote: > > > > > > On Wed, May 13, 2015 at

On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com> wrote: > I'm not sure this is a particularly great assumption to make. Which part? > We have to > support a lot of different build systems and tools and concentrating on > something that just binutils uses isn't particularly friendly here. I think you may have misunderstood His point was exactly

On Thu, May 14, 2015 at 2:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:35 PM Teresa Johnson <tejohnson at google.com> wrote: >> >> On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Thu, May 14, 2015 at 1:11 PM David Blaikie

On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:11 PM David Blaikie <dblaikie at gmail.com> wrote: >> >> On Thu, May 14, 2015 at 12:53 PM, Eric Christopher <echristo at gmail.com> >> wrote: >>> >>> >>> >>> On Thu, May 14, 2015 at 11:34 AM Daniel Berlin

On Thu, May 14, 2015 at 12:53 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 11:34 AM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com> >> wrote: >> > I'm not sure this is a particularly great assumption to make. >>

This looks similar to the problem I fixed awhile back in r292408. I'll take a look (probably tomorrow since I am taking some vacation today). Teresa On Tue, May 16, 2017 at 9:43 AM, David Blaikie <dblaikie at gmail.com> wrote: > +Teresa > > On Mon, May 15, 2017 at 9:20 AM David Callahan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I am tracking a

On Thu, May 14, 2015 at 2:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:35 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Thu, May 14, 2015 at 1:11 PM David Blaikie

On Wed, May 13, 2015 at 10:46 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > "ELF-wrapped bitcode" seems potentially controversial to me. > > What about ar, nm, and various ld implementations adds this requirement? > What about the LLVM implementations of these tools is lacking? > Sorry I can not parse your questions properly. Can you make it clearer? David

There is no need for emitting the full symtab. I checked the overhead with a huge internal C++ source. The overhead of symtab + str table compared with byte code with debug is about 3%. More importantly, it is also possible to use the symtab also for index/summary purpose, which makes the space usage completely 'unwasted'. That gets into the details which will follow when patches are in.

On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at leftfield.org> > wrote: > > My earlier statement about wrapping things in a native object file held > in that it is controversial. It appears to be still central to your design. > > > > It may help to look at the

To compile an auto-tooled project to bitcode, I used to use plugin-opt=save-temps switch as explained in: http://gbalats.github.io/2015/12/10/compiling-autotooled-projects-to-LLVM-bitcode.html. This switch works with LLVM 3.8.0. However, it seems to have no effect with LLVM 5.0.0. I can see intermediate bitcode files on disk, but not the final one. Is the option removed altogether? Has the switch

Hi Mehdi, Saw David's response but wanted to add a bit more below. On Fri, Aug 14, 2015 at 11:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 14, 2015, at 10:41 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Fri, Aug 14, 2015 at 3:35 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> Hi Teresa, >>

I've included below an RFC for implementing ThinLTO in LLVM, looking forward to feedback and questions. Thanks! Teresa RFC to discuss plans for implementing ThinLTO upstream. Background can be found in slides from EuroLLVM 2015: https://drive.google.com/open?id=0B036uwnWM6RWWER1ZEl5SUNENjQ&authuser=0) As described in the talk, we have a prototype implementation, and would like to