similar to: RFC: EfficiencySanitizer Cache Fragmentation tool

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

Have you consider naming it `performance sanitizer` instead? I believe that it would be easier to misheard esan with asan, and psan would solve it. Besides, looks like 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

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

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

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

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

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

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

LLVM3.8 version. https://bugs.llvm.org//show_bug.cgi?id=24233. The example can catch exception. But I use my own code for testing, CustomEHMemoryManager allocated memory address is very large, allocateCodeSection, allocateDataSection assigned address (more than 32 bit address space) is getting smaller and smaller. Cause registerEHFrames to fail. 3.9.1 or 4.0.0 version has been supported on win

+nlewycky On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch > wrote: > Hi Kostya, > > On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov < > vova.kuznetsov at epfl.ch> wrote: > > Do you think moving the pass to lib/Transform/Instrumentation but > > scheduling it during code generation would make sense ? If so, we'll >

Hi, I'm using IR and MCJIT to compile a script language. I debug it with on the fly generated .pdb files. During debugging, almost each time I step into a function, I loose information about calling function inside the visual studio callstack view or I have a bunch of pure addresses in the callstack in between the current function and the calling function, for example :

For help: Llvm generated instruction calls a function (extern), the function will have a SEH exception (EXCEPTION_ACCESS_VIOLATION), But JIT can not capture the exception of the EXCEPTION_ACCESS_VIOLATION. I saw Bug 24233. EXCEPTION_ACCESS_VIOLATION exception cannot be captured after modification. How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 ? haifeng.qin at wellintech.com

Hi all, I have recently encountered a problem when creating LLVM IRs. I am wondering if there is a standard or easy way to create a load from a certain register? For example, CreateLoad(rbp, NAME). Thanks, Chen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131213/ec277276/attachment.html>

Hi David and Mats, Thanks for your explanation. If my understanding is correct, it means we don't need to consider the side-effect of malloc/free unless compiling with -ffreestanding. Because without -ffreestanding, user defined malloc/free should be compatible with std library. It makes sense to me. My point is, in std library, malloc is allowed to return null if this malloc failed. Why