similar to: [LLVMdev] Automating Diagnostic Instrumentation

Reid, Adding this kind of instrumentation pass would be very valuable in LLVM. We don't have any such thing at present, and there could be multiple uses for it. Joel Stanley did an MS thesis last year that could complement this kind of pass nicely. Joel's thesis was on dynamic performance instrumentation guided by explicit queries within the application (I will forward you a

On Wed, 7 Apr 2004, Reid Spencer wrote: > (2) Would it be useful to turn the call graph data ino a pretty picture > via graphviz (both statically and dynamically) ? Sure: analyze -print-callgraph foo.bc > (3) How much of this auto-instrumentation pass is already written in > existing passes? There are various instrumentation passes already in LLVM, for example, to trace

Hello, I'd like to listen your opinions regarding my research with LLVM. My work is a dynamic analysis of data dependences [1]. Briefly speaking, I'm instrumenting memory loads/stores and loop entries/exits/back edges, and then calculating data dependences in runtime, especially focusing on loop-carried dependences. So far, I have been working with a binary-level instrumentation tool

Hi, We serve a fairly substantial number[1] of ssh connections across our fleet.? We have hit MaxStartups limits in the past and bumped it up a few times (currently at 300), but we have no warning before the limit is reached and connections start being dropped.? What I would love is some sort of instrumentation that could let us see the highest number of concurrent pre-auth connections the

Hi All, My instrumentation code needs to insert calls to transmit Value list. Each element in this list could be of different type. The list is sent to instrumenting function say void recordVarInputValues(int num, ...) . So, I have created a Union type in Tracing.cpp, which I link with my benchmark module at compile time. These steps are similar to giri instrumentation

> On Jun 17, 2016, at 11:27 AM, TB Schardl via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hey Ben, > > Thank you for your comments. I've put my response inline. > > Cheers, > TB > > On Fri, Jun 17, 2016 at 6:29 AM, Craig, Ben via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 6/16/2016 2:48 PM,

Accidentally sent to uiuc server. On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> wrote: > Can you compare your results with another approach: simply do not > instrument the top 1% hottest functions (by function entry count)? If this > simple approach provides most of the benefits (my measurements on one > codebase I tested show that it would eliminate

Chandler Carruth <chandlerc at google.com> writes: > The other assumption here is that you want the same file format written by > instrumentation and read back by the compiler. While I think that is an > unsurprising goal, I think it creates quite a few limitations that I'd like to > point out. I think it would be worthwhile to consider the alternative of > having the

Instrumentation based Profile Guided Optimization (PGO) is a compiler technique that leverages important program runtime information, such as precise edge counts and frequent value information, to make frequently executed code run faster. It's proven to be one of the most effective ways to improve program performance. An important design point of PGO is to decide where to place the

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

On Sat, Aug 8, 2015 at 6:31 AM, Xinliang David Li <davidxl at google.com> wrote: > On Fri, Aug 7, 2015 at 10:56 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Accidentally sent to uiuc server. > > > > > > On Fri, Aug 7, 2015 at 10:49 PM, Sean Silva <chisophugis at gmail.com> > wrote: > >> > >> Can you compare your results

On 12/7/11 4:51 PM, Nipun Arora wrote: > Hi, > > I need to write a transform pass which instruments the target program to > output the name of each function executed, and the rdtsc counter along > with it. Doing this in LLVM is really straightforward. You simply iterate through all the functions in a module and add instructions to their entry basic blocks to do whatever it is

Hi, @Alastair: Thanks a bunch for explaining this so well. I was able to write a simple profiler, and run it. I need to profile the code for branches (branch mis predicts simulation), load/store instructions (for cache hits/miss rate), and a couple of other things and therefore, would need to instrument the code. However, I would like to know if writing the output to a file would increase the

Hi, I need to write a transform pass which instruments the target program to output the name of each function executed, and the rdtsc counter along with it. Can anyone give me an idea of how to go about it?(I've worked around with LLVM pass framework and opt to do static analysis, but would like to do a lightweight instrumentation). Also can anyone give an approximate idea of the

Hi John, Thanks for the detailed answer, this gives me a good starting point to look into. I was also wondering if you could give an idea (in terms of %ge) the overhead one can expect with such an instrumentation. I want something really lightweight and simple which can possible be applied to production systems, so overhead is a concern. Thanks Nipun On 12/09/2011 02:21 PM, John Criswell

On Tue, Sep 1, 2015 at 2:32 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Tue, Sep 1, 2015 at 2:10 PM, Xinliang David Li <davidxl at google.com> > wrote: >> >> This is a late reply -- the email somehow skipped my inbox. >> >> > Philip and Sanjoy, out of curiosity do you guys use your own >> > instrumentation >> >

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

Hi John and Silky, I can see a copy of 'giri' slicing project branch here http://llvm.org/viewvc/llvm-project/giri/. Though it may be little older, it will work I think. You can look at the code to see how we do the instrumentation. Thanks, Swarup. ________________________________________ From: John Criswell [criswell at illinois.edu] Sent: Tuesday, January 22, 2013 10:29 AM To:

One aspect of this that I have not seen discussed is that middle-end instrumentation enables PGO optimizations to front-ends other than Clang. While I agree that FE instrumentation could be improved, it still requires every FE to implement essentially the same common functionality. Having PGO instrumentation generated in the middle-end, allows us every FE to automatically take advantage of PGO.

I am very glad this project reached the state where we can start the public code review. Please shoot the patches for review when ready. --kcc On Thu, Jun 16, 2016 at 12:14 PM, TB Schardl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > CC'ing the mailing list for the CSI project. > > On Thu, Jun 16, 2016 at 12:01 PM, TB Schardl <neboat at mit.edu> wrote: >