similar to: [LLVMdev] Efficient instrumentation of loads and stores

Dear Dibyendu, Thanks for your response. :-) > If you are looking for only dependences which are inter-iteration (dependence distance != 0 ) you can do a post-pass on the ld/st addresses collected Yes, I am more interested in inter-iteration dependence. Could you provide more information or some links on post-pass approach? I have no idea on your method. :-) > eliminate such

Dear Dibyendu and Mobi, Thanks for your help! :-) I finally figure it out. The solution is really simple. I just need to generate a new bitcode file with the following command: ----- opt -mem2reg -indvars test1.bc -o test2.bc ----- Then the load/store for induction variables will be removed and replaced by PHI instructions and all remaining load/store instructions are those I am interested in. I

Hi LLVM-ers, I try to develop my custom dynamic data dependence tool (focusing on nested loops), currently I can successfully get the trace including load/store address, loop information, etc. However, when I try to analyze dynamic data dependence based on the pairwise method described in [1], the load/store for iteration variables may interfere my analysis (I only care about the load/store for

Hi Timo, Thanks for commenting. I feel like I have to justify why I don't want to use QEMU, which is fine since my choice is not frozen actually. QEMU is much more than what I need for dynamically instrumenting software. My goal is automated testing to find bugs, which can quickly be intensive in term of computational load. Thus I am trying to get the smallest (and fastest) tool. Even using

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, Sep 29, 2009 at 14:21, Alexandre Gouraud <alexandre.gouraud at enst-bretagne.fr> wrote: > Hi Timo, > > Thanks for commenting. I feel like I have to justify why I don't want to use > QEMU, which is fine since my choice is not frozen actually. > > QEMU is much more than what I need for dynamically instrumenting software. > My goal is automated testing to find

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

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.

On 1/13/13 11:06 PM, Criswell, John T wrote: > There is code that does this for older versions of LLVM. I believe it is in the giri project in the LLVM SVN repository. I can look into more details when I get back from vacation. Swarup may also be able to provide information on the giri code. I took a quick look, and the dynamic slicing code doesn't appear to be checked into the giri

This is a late reply -- the email somehow skipped my inbox. > Philip and Sanjoy, out of curiosity do you guys use your own instrumentation > placement for PGO? Is an IR-level PGO infrastructure upstream something you > guys would be interested in? > > I think that 2. is something that once we have 1. we will be able to > evaluate better, but for now my opinion is that we should

LLVMers, I need to intercept all LLVM IR instructions that will write into memory and start to do analysis on these instructions. In addition to StoreInst, what are all other IRs that will write into memory? E.g. char * ptr = malloc(...); ///... //with use(s) of ptr later The LLVM IR for the above code would be: %0 = tail call noalias i8* @malloc(i32 137) nounwind ///... //

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

We collected more data to address some of the questions from the reviewers. Note this time we use clang itself as the benchmark. We choose clang because we think it's a typical C++ program and the reviewers here have good knowledge of the code base. What we measure is running time for clang to compile a large preprocessed source file (4.98M lines of .ii file), using different compilation

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:

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 Tue, Oct 25, 2011 at 5:06 AM, Bill Wendling <wendling at apple.com> wrote: > Good day! > > To get ready for the release, we need to make sure that the list of external open source projects using LLVM 3.0 (file:///Volumes/Sandbox/llvm/llvm.src/docs/ReleaseNotes.html#externalproj) is up to date. Please send me an email with the project's name and a short description of it.

On 1/22/13 12:07 PM, Sahoo, Swarup Kumar wrote: > 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. The giri project is supposed to contain both the static slicing code and the dynamic

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

Justin, Sean and other people interested in this proposal, I'm wondering if you have chances to read the new experiment results in my last email sent 2 weeks ago. Can you share you thoughts, or you have other tests that you want to to run? I'm in the final stage of preparing the patch. If you are OK, I can sent out the patch soon. Thanks, -Rong On Wed, Aug 19, 2015 at 5:18 PM, Philip