similar to: 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 the like on ooo cores. > Won't hardware performance counter tell you which accesses are delinquent accesses? The

On Tue, Apr 19, 2016 at 11:19 PM, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Some of this data might be interesting for profile guidance. Are there any > plans there? > > Esan instrumentation is geared toward application level tuning by developers -- the data collected here are not quite 'actionable' by the compiler directly. For instance, struct

On Thu, Apr 21, 2016 at 1:57 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Qin Zhao" <zhaoqin at google.com> > *To: *"Hal Finkel" <hfinkel at anl.gov> > *Cc: *"Derek Bruening" <bruening at google.com>, > efficiency-sanitizer at google.com, "llvm-dev" <llvm-dev

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

On Tue, Apr 19, 2016 at 10:18 AM Filipe Cabecinhas via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Apr 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 > >

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 fragmentation. Knowing the cache fragmentation information

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

Thanks for the comment and suggestions. That's a great idea! We actually thought about using each heap object with its type information for more accurate data, and it is definitely in our future plan. However, there are challenges to do so. For example, getting correct type information for each heap object might not be easy, especially for C programs. An application can even use a custom

On Tue, Apr 19, 2016 at 1:18 PM, Filipe Cabecinhas <filcab at gmail.com> wrote: > Thanks for proposing this. It seems like it might be an interesting > tool for us too. But this proposal seems a bit hand-wavy, and I think > it's missing some crucial info before we start heading this way. > > At least for the tools you are currently starting to implement, it > would be

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

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, how its behavior changes over time, how its

> From: piotrekpad at gmail.com [mailto:piotrekpad at gmail.com] On Behalf Of Piotr Padlewski > Sent: den 16 oktober 2017 17:33 > > Hi David, > The patch didn't get a lot of attention, so probably others does not > consider it a huge deal. Anyway, if someone is willing to review this, I > can pursue rebasing it. Okay. We are interested in getting something akin to your

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

Dear R users, I have a dataset with two variables: $esan - a grouping factor with 8 levels and $reus. I'd like to do wilcox.test on this dataset as sugested Weiwei here: https://stat.ethz.ch/pipermail/r-help/2007-July/136627.html. I tried to adapt his recommendation but no succes. Can anyone help me? Regards, Iurie Malai, Senior Lecturer Department of Psychology Faculty of Psychology and

There are another things left: 1. Adding check for ubsan to detect UBs caused by inplace new 2. upgrading GVN to optimize based on !invariant.group across BBs 3. Adding something like "nocapture-global" that will say that this pointer is not being captured by global, but may be captured for example by returning it from function. This thing is important because this is exactly what

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

On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> wrote: > There is some misunderstanding about the intention of this flag. The > purpose of the flag is not to turn on profile instrumentation (which > already has -fprofile-instr-generate or -fprofile-generate for it), but to > select which instrumentors to use for PGO (IR or FE). I prefer fewer flags

I need to create a couple of tie lines between a legacy system and an Asterisk system. I was told that the tie lines are E4 Superframe E&M. I have done E&M wink but have no idea about E4 Superframe E&M and Google is not helping me here. Does anyone know about this type of signaling and if Asterisk can handle it? Thanks, Steve

On Sun, Jun 26, 2016 at 10:21 PM, Dean Michael Berris <dberris at google.com> wrote: > > > On Mon, Jun 27, 2016 at 2:53 PM Xinliang David Li <davidxl at google.com> > wrote: > >> There is some misunderstanding about the intention of this flag. The >> purpose of the flag is not to turn on profile instrumentation (which >> already has