search for: propelled

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

On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com> wrote: > > > -----Original Message----- > > From: Sriraman Tallam <tmsriram at google.com> > > Sent: Friday, September 27, 2019 9:43 AM > > To: Eli Friedman <efriedma at quicinc.com> > > Cc: Xinliang David Li <xinliangli at gmail.com>; llvm-dev <llvm-dev at

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

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 llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Sep 27, 2019 at 1:16 PM Eli Friedman <efriedma at quicinc.com> > wrote: > > > > > > > -----Original Message----- > > > > From:

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

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

...bc a.o -o lto/a.o $(clang) -O2 -c -fthinlto-index=lto/b.o.thinlto.bc b.o -o lto/b.o final_link exe: lto/a.o lto/b.o a.rsp # Propeller does basic block section reordering here. $(clang) -fuse-ld=lld @a.rsp -o exe We need to replace the two stages thinlto_backend and final_link with three. Propelled ThinLTO with minimized bitcode files: propelled_thinlto_backend lto/a.mir lto/b.mir: a.o b.o lto/a.o.thinlto.bc lto/b.o.thinlto.bc # Propeller emits something similar to a Machine IR file. # a.o and b.o are all IR files. $(clang) -O2 -c -fthinlto-index=lto/a.o.thinlto.bc -fpropeller a.o -o...

I have a data file that looks like this class pigeon falcon propeller jet wing fly birds 25 37 0 0 2 1 planes 0 1 28 40 1 3 birds 19 41 0 1 4 6 planes 0 0 25 50 5 5 planes 1 0

On Tue, Nov 27, 2012 at 8:58 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 11/27/2012 8:03 AM, Hal Finkel wrote: > >> >> This still leaves the question of exactly how to attach metadata to >> loops, etc. >> > > In one implementation, the loops had a fixed structure: guard branch, > preheader, header and loop body, optional epilog.

Some more information about the relaxation pass whose effectiveness and convergence guarantees were listed as a concern: TLDR; Our relaxation pass is similar to what LLVM’s MCAssembler does but with a caveat for efficiency. Our experimental results show it is efficient and convergence is guaranteed. Our relaxation pass is very similar to what MCAssembler does as it needs to solve the same

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

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

Hello, I wanted to consolidate all the discussions and our final thoughts on the concerns raised. I have attached a document consolidating it. BOLT’s performance gains inspired this work and we believe BOLT is a great piece of engineering. However, there are build environments where scalability is critical and memory limits per process are tight : * Debug Fission,

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

Hello Maksim, On Wed, Oct 16, 2019 at 3:52 PM Maksim Panchenko <maks at fb.com> wrote: > Hi Sri, > > > > I want to clarify one thing before sending a detailed reply: did you > evaluate > > BOLT on Clang built with basic block sections? > In the makefile you reference, > > there are two versions: a “vanilla” and a default built with function > sections.

On Wed, Oct 2, 2019 at 8:41 PM Maksim Panchenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > *Pessimization/overhead for stack unwinding used by system-wide profilers > and > for exception handling* > > Larger CFI programs put an extra burden on unwinding at runtime as more CFI > (and thus native) instructions have to be executed. This will cause more > overhead