similar to: A Propeller link (similar to a Thin Link as used by ThinLTO)?

Greetings, We, at Google, recently evaluated Facebook’s BOLT, a Post Link Optimizer framework, on large google benchmarks and noticed that it improves key performance metrics of these benchmarks by 2% to 6%, which is pretty impressive as this is over and above a baseline binaryalready heavily optimized with ThinLTO + PGO. Furthermore, BOLT is also able to improve the performance of binaries

I guess Eric means full program optimization/cross module optimization using MIR. This is in theory workable in full LTO style, but not in ThinLTO style which works on summary data. As we have discussed, eliminating monolithic style optimization is the key design goal. This was also briefly discussed in one of the previous replies I sent. There are other benefits of doing this in linker such

On Mon, Sep 30, 2019 at 1:27 PM Eric Christopher <echristo at gmail.com> wrote: > On Mon, Sep 30, 2019 at 12:31 PM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam

On Wed, Sep 25, 2019 at 5:02 PM Eli Friedman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My biggest question about this architecture is about when propeller runs > basic block reordering within a function. It seems like a lot of the > complexity comes from using the proposed -fbasicblock-sections to generated > mangled ELF, and then re-parsing the mangled ELF as a

On Thu, Sep 26, 2019 at 6:16 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > -----Original Message----- > > From: Sriraman Tallam <tmsriram at google.com> > > Sent: Thursday, September 26, 2019 5:31 PM > > To: Eli Friedman <efriedma at quicinc.com> > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <llvm-dev at

I am trying to work through the usage of thinlto for distributed builds. Here is the simple thinlto usage, just add -flto=thin everywhere, easy: clang++ -flto=thin -O3 -c -o CreateWay_.o -DSPEC_CPU -DNDEBUG -DSPEC_CPU_LITTLE_ENDIAN -Wno-dangling-else CreateWay_.cpp clang++ -flto=thin -O3 -c -o Places_.o -DSPEC_CPU -DNDEBUG -DSPEC_CPU_LITTLE_ENDIAN

Thanks Teresa Yes it is astar, happen to send a tar of the sources but they are just copies from the spec distribution The ld command is: GNU ld (GNU Binutils) 2.29.1 Thanks for the guidance on path names. The prefix-replace just effects the string written to the object files right? So we could post-process that file with other tools as well, correct? Thanks again --david From: Teresa Johnson

Fails with gold too: Library-native.o:Library.cpp:regway: error: undefined reference to 'vtable for regwayobj' /home/dcallahan/fbsource/fbcode/third-party-buck/platform007/tools/binutils/bin/gold/ld: the vtable symbol may be undefined because the class is missing its key function clang-8: error: linker command failed with exit code 1 (use -v to see invocation) From: Teresa Johnson

We are going to be at the llvm-dev meeting the next two days. We will get back to you after that. Sri On Mon, Oct 21, 2019 at 10:07 PM Maksim Panchenko <maks at fb.com> wrote: > Hi Sri, > > > > Thank you for replying to our feedback. 7 out 12 high-level concerns have > been > > answered; 2 of them are fully addressed. The rest are being tracked at the > >

On Mon, Sep 30, 2019 at 12:26 PM Eric Christopher <echristo at gmail.com> wrote: > On Sat, Sep 28, 2019 at 8:25 AM Sriraman Tallam <tmsriram at google.com> > wrote: > > > > > > > > On Fri, Sep 27, 2019 at 10:36 PM Eric Christopher <echristo at gmail.com> > wrote: > >> > >> On Fri, Sep 27, 2019 at 2:08 PM Sriraman Tallam via

On Thu, Sep 26, 2019 at 12:39 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > > From: Xinliang David Li <xinliangli at gmail.com> > Sent: Wednesday, September 25, 2019 5:58 PM > To: Eli Friedman <efriedma at quicinc.com> > Cc: Sriraman Tallam <tmsriram at google.com>; llvm-dev <llvm-dev at lists.llvm.org> > Subject: [EXT] Re: [llvm-dev]

On Thu, Sep 26, 2019 at 5:13 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > -----Original Message----- > > From: Sriraman Tallam <tmsriram at google.com> > > Sent: Thursday, September 26, 2019 3:24 PM > > To: Eli Friedman <efriedma at quicinc.com> > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <llvm-dev at

Is there large value from deferring the block ordering to link time? That is, does the block layout algorithm need to consider global layout issues when deciding which blocks to put together and which to relegate to the far-away part of the code? Or, could the propellor-optimized compile step instead split each function into only 2 pieces -- one containing an "optimally-ordered" set of

I'm trying to run distributed ThinLTO without thin archives. When I do, I get an error in the optimizer when clang tries to open a nonexistent file: clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c main.cpp -o main.o clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c lib/lib.cpp -o lib/lib.o clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c src/lib.cpp -o src/lib.o llvm-ar -format gnu qcs lib.a

Hello Maksim, On Fri, Oct 18, 2019 at 10:57 AM Maksim Panchenko <maks at fb.com> wrote: > Cool. The new numbers look good. If you run BOLT with jemalloc library > > preloaded, you will likely get a runtime closer to 1 minute. We’ve noticed > that > > compared to the default malloc, it improves the multithreaded > > performance and brings down memory usage

Hi all, I updated the patches to remove the native object wrapper format. As suggested we will work on getting the ThinLTO framework in place using bitcode first, and then work on adding the native object support. As noted in this RFC and in the associated patch D11722, for now I have empty ThinLTO blocks with no records, since I wanted to get feedback on the overall block design first. The RFC

Thanks! Question about the final link step: Do I provide all the object files to the link step, i.e. something like: clang++ -o thinlto main-native.o lib/lib-native.o src/lib-native.o Do I need to provide --start-lib markers on that final link step as well? Tanoy On Tue, Jun 18, 2019 at 10:37 AM Teresa Johnson <tejohnson at google.com> wrote: > Hi Tanoy, > > You can't use

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

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

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