search for: efficiencysanit

.... Xref > > the Deadspy paper from CGO 2012. > > > > > > *Single-reference*: this tool identifies data cache lines brought in > > but only read once. These could be candidates for non-temporal > > loads. > > > > > > ==================== > > EfficiencySanitizer > > ==================== > > > > > > We are proposing the name EfficiencySanitizer, or "esan" for short, > > to refer to this suite of dynamic instrumentation tools for > > improving program efficiency. As we have a number of different tools > &g...

...ot;Hal Finkel" <hfinkel at anl.gov> > *Cc: *"Derek Bruening" <bruening at google.com>, > efficiency-sanitizer at google.com, "llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Thursday, April 21, 2016 12:48:20 PM > *Subject: *Re: [llvm-dev] RFC: EfficiencySanitizer > > >> Will this technology allow us to pinpoint specific accesses that >> generally have high latency (i.e. generally are cache misses)? This >> information is useful for programmers, and is also useful as an input to >> loop unrolling, instruction scheduling, and...

Please reference the prior RFC on EfficiencySanitizer. This is one of the performance analysis tools we would like to build under the EfficiencySanitizer umbrella. ==================== Motivation ==================== An application is running sub-optimally if only part of the data brought into the cache is used, which we call cache fragmentat...

...essage ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Qin Zhao" <zhaoqin at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, April 22, 2016 7:13:38 PM > Subject: Re: [llvm-dev] RFC: EfficiencySanitizer Cache Fragmentation > tool > ----- Original Message ----- > > From: "Qin Zhao via llvm-dev" <llvm-dev at lists.llvm.org> > > > To: "llvm-dev" <llvm-dev at lists.llvm.org> > > > Sent: Friday, April 22, 2016 4:59:00 PM > > &...

...lt;hfinkel at anl.gov> > *To: *"Hal Finkel" <hfinkel at anl.gov> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org>, "Qin Zhao" <zhaoqin at google.com > > > *Sent: *Friday, April 22, 2016 7:18:03 PM > > *Subject: *Re: [llvm-dev] RFC: EfficiencySanitizer Cache Fragmentation > tool > > > > ------------------------------ > > *From: *"Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"Qin Zhao" <zhaoqin at google.com> > *Cc: *"llvm-dev" <llvm-dev at lists.llvm.org&...

...fun! Good luck Piotr 17.04.2016 11:46 PM "Derek Bruening via llvm-dev" <llvm-dev at lists.llvm.org> napisał(a): TL;DR: We plan to build a suite of compiler-based dynamic instrumentation tools for analyzing targeted performance problems. These tools will all live under a new "EfficiencySanitizer" (or "esan") sanitizer umbrella, as they will share significant portions of their implementations. ==================== Motivation ==================== Our goal is to build a suite of dynamic instrumentation tools for analyzing particular performance problems that are difficult...

...pr 17, 2016 at 10:46 PM, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > TL;DR: We plan to build a suite of compiler-based dynamic instrumentation > > tools for analyzing targeted performance problems. These tools will all > > live under a new "EfficiencySanitizer" (or "esan") sanitizer umbrella, as > > they will share significant portions of their implementations. > > I will bike-shed the name as much as anyone else, but I'll stay away for > now :-) > > > > While these tools are not addressing correctness i...

...17, 2016 at 2:46 PM, Derek Bruening via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> TL;DR: We plan to build a suite of compiler-based dynamic instrumentation >> tools for analyzing targeted performance problems. These tools will all >> live under a new "EfficiencySanitizer" (or "esan") sanitizer umbrella, as >> they will share significant portions of their implementations. >> >> ==================== >> Motivation >> ==================== >> >> Our goal is to build a suite of dynamic instrumentation tools for...

...existing sanitizers. Each tool will have inlined instrumentation to update shadow memory on either every memory access or in some cases just focusing on the heap; I do not have a number for code size expansion. The slowdown ranges were in the original email: 2x-5x. > We are proposing the name EfficiencySanitizer, or "esan" for short, to > refer > > to this suite of dynamic instrumentation tools for improving program > > efficiency. As we have a number of different tools that share quite a > bit > > of their implementation we plan to consider them sub-tools under the &...

TL;DR: We plan to build a suite of compiler-based dynamic instrumentation tools for analyzing targeted performance problems. These tools will all live under a new "EfficiencySanitizer" (or "esan") sanitizer umbrella, as they will share significant portions of their implementations. ==================== Motivation ==================== Our goal is to build a suite of dynamic instrumentation tools for analyzing particular performance problems that are difficult...

On Wed, Apr 20, 2016 at 2:48 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Tue, Apr 19, 2016 at 10:44 PM, Derek Bruening via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Please reference the prior RFC on EfficiencySanitizer. This is one of >> the performance analysis tools we would like to build under the >> EfficiencySanitizer umbrella. >> >> ==================== >> Motivation >> ==================== >> >> Knowing the working set size at periodic points during a gi...

Please reference the prior RFC on EfficiencySanitizer. This is one of the performance analysis tools we would like to build under the EfficiencySanitizer umbrella. ==================== Motivation ==================== Knowing the working set size at periodic points during a given application's execution helps to understand its cache behavior...

On Mon, Apr 18, 2016 at 1:36 PM, Craig, Ben via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 4/17/2016 4:46 PM, Derek Bruening via llvm-dev wrote: > > *Cache fragmentation*: this tool gather data structure field hotness > information, looking for data layout optimization opportunities by grouping > hot fields together to avoid data cache fragmentation. Future

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? >

On 04/20/2016 02:58 PM, Renato Golin via llvm-dev wrote: > Hi Derek, > > I'm not an expert in any of these topics, but I'm excited that you > guys are doing it. It seems like a missing piece that needs to be > filled. > > Some comments inline... > > > On 17 April 2016 at 22:46, Derek Bruening via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>

...[r270487](http://reviews.llvm.org/rL270487), [r271054](http://reviews.llvm.org/rL271054). * LLVM's stack colouring analysis data flow analysis has been rewritten in order to increase the number of stack variables that can be overlapped. [r270559](http://reviews.llvm.org/rL270559). * Parts of EfficiencySanitizer are starting to land, notably instrumentation for its working set tool. [r270640](http://reviews.llvm.org/rL270640). * SelectionDAG learned how to expand multiplication for larger integer types where there isn't a standard runtime call to handle it. [r270720](http://reviews.llvm.org/rL2707...