search for: instrumenting

...E >> instrumentation slowdown : >> * [Main] Redundant counter updates of inlined functions. C++ programs >> can introduce large abstraction penalties by using lots of small inline >> functions (assignment operators, getters, setters, ctors/dtors etc). >> Overhead of instrumenting those small functions can be very large, making >> training runs too slow and in some cases to usable; >> * Non-optimal placement of the count updates; >> * A third factor is related value profiling (to be turned on in the >> future). Small and hot callee functions tak...

...p 1% were just trivial getters and constructors or similar. We should already be "getting these right". Stuff like: class Foo { .... Foo(int bar) : m_bar(bar) {} int getBar() { return m_bar; } ... }; Are the results different for your codebases? Have you tried something like simply not instrumenting the hottest 1% or 0.5% of functions? (maybe restrict the instrumentation skipping to functions of just a single BB with less than, say, 10 instructions). Rong's approach is quite sophisticated; I'm just interested on getting a sanity check against a "naive" approach to see how mu...

...e are 3 important factors contributing to FE instrumentation slowdown : * [Main] Redundant counter updates of inlined functions. C++ programs can introduce large abstraction penalties by using lots of small inline functions (assignment operators, getters, setters, ctors/dtors etc). Overhead of instrumenting those small functions can be very large, making training runs too slow and in some cases to usable; * Non-optimal placement of the count updates; * A third factor is related value profiling (to be turned on in the future). Small and hot callee functions taking function pointer (callbacks) can...

Hi all, I want to test X-ray performance and compare it with other research tools, so I use Clang 7.0.0 to compile and instrument GNU binutils-2.3.1 with the following commands: cd binutils-2.31/ mkdir build cd build/ CC=$local/clang CXX=$local/clang++ CFLAGS=-fxray-instrument CXXFLAGS=-fxray-instrument ../configure --prefix=/home/zhangysh1995/local make Then I extract instrumentation map

Hello, I have some questions about removing the instrumented instructions at runtime. Assume I instrument some instructions by using some transformation passes. At runtime, I just need those instrumented instructions at the beginning, and I would like to remove instrumented instructions at runtime to reduce overhead. Does anyone know how to do this by using LLVM? Thanks, Bo -- View

Hello all, I have developed a instrumented pass which insert some variables between the original variables, as well as insert some code into the original source code. just like: ============= original source code ============= int a[10]; void fun1 () { // some source code here } ========================================= ============= instrumented source code ============= int

...uninstrumented code. ================ CSI version 1 ================ The initial version of CSI supports a basic set of hooks that covers the following categories of program objects: functions, function exits (specifically, returns), basic blocks, call sites, loads, and stores. We prioritized instrumenting these IR objects based on the need of seven example CSI tools, including a race detector, a cache-reuse analyzer, and a code-coverage analyzer. We plan to evolve the CSI API over time to be more comprehensive, and we have designed the CSI API to be extensible, allowing new instrumentation to be ad...

> Assume I instrument some instructions by using some transformation passes. > At runtime, I just need those instrumented instructions at the beginning, > and I would like to remove instrumented instructions at runtime to reduce > overhead. At the beginning of what? You mean at the time of program starup? Then after detecting/collecting whatever you want, you would like to remove

...======= > CSI version 1 > ================ > > The initial version of CSI supports a basic set of hooks that covers the > following categories of program objects: functions, function exits > (specifically, returns), basic blocks, call sites, loads, and stores. We > prioritized instrumenting these IR objects based on the need of seven > example CSI tools, including a race detector, a cache-reuse analyzer, and a > code-coverage analyzer. We plan to evolve the CSI API over time to be more > comprehensive, and we have designed the CSI API to be extensible, allowing > new inst...

...alls and is a leaf node in the call chain). In between these two extremes (root and leaf), the call chain will fan-in (like strlen) and fan-out (like main). Architecturally, we can speak of the fan-out points being the places in the application code where a module boundary is being crossed. By instrumenting these fan-out points we can be assured that we're instrumenting things that (a) have architectural significance (i.e. good quality of information) and (b) imply enough processing that the overhead of instrumentation is negligible. With the above kind of instrumentation in mind, I consider su...

Thanks Vedant, and my apologies for the delay getting back to you - work got "busy". I wasn't aware of the '-fprofile-generate' option, so thanks for point this out. I have tried running it and I can see the instrumentation hooks that it generates - I assume that there is a library I have to implement to support this, can you let me know where the source for this library

...1 >> ================ >> >> The initial version of CSI supports a basic set of hooks that covers the >> following categories of program objects: functions, function exits >> (specifically, returns), basic blocks, call sites, loads, and stores. We >> prioritized instrumenting these IR objects based on the need of seven >> example CSI tools, including a race detector, a cache-reuse analyzer, and a >> code-coverage analyzer. We plan to evolve the CSI API over time to be more >> comprehensive, and we have designed the CSI API to be extensible, allowing &...

Hi, I consider reducing the usage of blacklist in sanitizer instrumentation passes and doing the necessary work in frontend (Clang) instead. Some of it is already implemented: e.g. Clang will attach an attribute "sanitize_address" to function definition only if this function is not blacklisted. In this case we won't instrument the memory accesses in this function in ASan

> On Dec 13, 2016, at 3:46 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > When either ‘-pg’ or ‘-finstrument-functions’ is used, the compiler inserts the appropriate profiling hooks. This happens prior to inlining, so the hooks remain in place. Have you tried compiling with -fprofile-generate? It enables IR-based profiling instrumentation, which

...call chain). > In > between these two extremes (root and leaf), the call chain will fan-in > (like strlen) and fan-out (like main). Architecturally, we can speak > of > the fan-out points being the places in the application code where a > module boundary is being crossed. By instrumenting these fan-out > points > we can be assured that we're instrumenting things that (a) have > architectural significance (i.e. good quality of information) and (b) > imply enough processing that the overhead of instrumentation is > negligible. > > With the above kind of instr...

Hello, I have a question regarding PGO instrumented BBs (I use IR-level instrumentation). It seems that instrumented BBs do not match between the two compilations for profile-gen and profile-use for some cases. Here is an example from SPECcpu 2006 lbm (a simple case consisting of just two modules). In the first compilation, we have 5 instrumentation points for the main function as follows: $

...t; >> ================ >> >> The initial version of CSI supports a basic set of hooks that covers the >> following categories of program objects: functions, function exits >> (specifically, returns), basic blocks, call sites, loads, and stores. We >> prioritized instrumenting these IR objects based on the need of seven >> example CSI tools, including a race detector, a cache-reuse analyzer, and a >> code-coverage analyzer. We plan to evolve the CSI API over time to be more >> comprehensive, and we have designed the CSI API to be extensible, allowing &...

On 2/24/13 10:07 AM, Lu Mitnick wrote: > Hello all, > > I have developed a instrumented pass which insert some variables > between the original variables, > as well as insert some code into the original source code. just like: > > ============= original source code ============= > > int a[10]; > > void fun1 () { > // some source code here > } > >

Hi there, I hope to build a model Y ~ X1 + X2 + X3 + X4 with X1 has two instrumental variable A and B, and X2 has one instrumental variable A. I have searched the R site and mailling list, and known that the tsls() from sem package and ivreg() from AER package can deal with instrumental variable regression, however, I don't know how to formula the model. Any suggestion will be really

...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 modes. All the numbers reported here are the average running time of 5 runs in seconds. *(1) Performance b/w late instrumentation v.s. not instrumenting single BB functions* We first compare various instrumentation performance. ---------------------------------------------------------------------------- Config wall_time_for_instr ratio_vs_base profile_size (1) base O2 80.386 100.0% --...