search for: toolchaing

Displaying 8 results from an estimated 8 matches for "toolchaing".

Did you mean: toolchain
2017 Nov 08
2
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
...sing the visibility attribute. I don't think that we can observe noticeable difference in performance between Initial Exec and Local Exec except an synthetic benchmark though. The nice thing about linker relaxations is that they are very user > friendly. The linker is the first point in the toolchaing where some > usefull fact is know, and it can optimize the result with no user > intervention. I think I agree with this point. Automatic linker code relaxation is convenient and if it makes a difference, we should implement that. But I'd doubt if TLS relaxation is actually effective. G...
2017 Nov 08
2
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
...in the first place. The point is that if to switch to lld and keep > performance users should not have to annotate all tls variables with > tls-model. > > > The nice thing about linker relaxations is that they are very user > >> friendly. The linker is the first point in the toolchaing where some > >> usefull fact is know, and it can optimize the result with no user > >> intervention. > > > > > > I think I agree with this point. Automatic linker code relaxation is > > convenient and if it makes a difference, we should implement that. But...
2017 Nov 08
2
[RFC] lld: Dropping TLS relaxations in favor of TLSDESC
On Tue, Nov 7, 2017 at 6:59 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > tl;dr: TLSDESC have solved most problems in formerly inefficient TLS > access > > models, so I think we can drop TLS relaxation support from lld. > > > > lld's code to handle
2019 Oct 17
2
[RFC] Propeller: A frame work for Post Link Optimizations
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.
2019 Oct 14
2
[RFC] Propeller: A frame work for Post Link Optimizations
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,
2019 Oct 18
3
[RFC] Propeller: A frame work for Post Link Optimizations
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
2019 Oct 22
2
[RFC] Propeller: A frame work for Post Link Optimizations
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 > >
2019 Oct 11
2
[RFC] Propeller: A frame work for Post Link Optimizations
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