search for: finstrument

Hi, I'd like to track not just at the function level, but also at the code block level. For example, for a if-else statement, I want to know when the if-branch or else-branch is enter/exit. Is there a clang option similar to -finstrument-functions for code blocks? Alternatively, I could manually insert the code to the IR .ll file. I see the generated .ll use the following function when -finstrument-functions is enabled. Is there an equivalent function for code blocks? %1 = call i8* @llvm.returnaddress(i32 0), !dbg !10 -- Regar...

...egration with PGO instrumentation, both (A) and (B) should > work. For (B), we need to increase the number of per function counters by > one. For (A), they will be in different sections. > > (C) XRay > We have not looked into this, but would like to hear more about it! > > (D) -finstrument-functions-after-inlining or > -finstrument-function-entry-bare > We are worried about the runtime overhead of calling a separate function > when starting up the App. > > Thanks, > Manman > > On Fri, Jan 18, 2019 at 2:01 PM Chris Bieneman <chris.bieneman at me.com> >...

...of the functions. We only log the function when it is first executed. Instead of logging the symbol name of the function, we log a pair of integers, with one integer specifying the module id, and the other specifying the function id within the module. > > [...] > >> clang has '-finstrument-function-entry-bare' which inserts a function call and is not as efficient. > > Can you elaborate on why this existing functionality is not efficient > enough for you? > > For Chrome on Windows, we use -finstrument-functions-after-inlining to > insert calls at function entry...

...what I was suggesting > in the x-ray thread before seeing this. > > +1 to -fprofile-instrument=... (as someone working on the XRay stuff, I'd much rather have less flags, and consolidate a lot of these similar things into a more inclusive flag). I would even make it shorter, and say -finstrument={profile-..., xray-...} so we can have multiple "namespaced" values for -finstrument=. Just my A$0.02. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160627/5b678449/attachment.html>

...>> should work. For (B), we need to increase the number of per function >>> counters by one. For (A), they will be in different sections. >>> >>> (C) XRay >>> We have not looked into this, but would like to hear more about it! >>> >>> (D) -finstrument-functions-after-inlining or >>> -finstrument-function-entry-bare >>> We are worried about the runtime overhead of calling a separate function >>> when starting up the App. >>> >>> Thanks, >>> Manman >>> >>> On Fri, Jan 18, 2019...

...: // In 'source.cpp' #pragma push profile instrumentation #pragma disable profile instrumentation #include "header.h" #pragma pop profile instrumentation ... X anX; ... int check = anX.getK(); or an alternative mechanism. The GCC compiler has the options '-finstrument-functions-exclude-file-list' and '-finstrument-functions-exclude-function-list' for this purpose, but these are not available in CLang/LLVM. I will experiment with the '-mllvm -disable-preinline' option, thanks for telling me about this too. All the best, MartinO -----Or...

...g this. >>> >>> >> +1 to -fprofile-instrument=... (as someone working on the XRay stuff, I'd >> much rather have less flags, and consolidate a lot of these similar things >> into a more inclusive flag). >> >> I would even make it shorter, and say -finstrument={profile-..., >> xray-...} so we can have multiple "namespaced" values for -finstrument=. >> >> Just my A$0.02. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201...

...he x-ray thread before seeing this. >> >> > +1 to -fprofile-instrument=... (as someone working on the XRay stuff, I'd > much rather have less flags, and consolidate a lot of these similar things > into a more inclusive flag). > > I would even make it shorter, and say -finstrument={profile-..., xray-...} > so we can have multiple "namespaced" values for -finstrument=. > > Just my A$0.02. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160626/ed3ac775/attachment....

> 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 has supported pre-inlining since r275588. That should miti...

..., log the module id and the function id, then atomically increase the index. This pass is intended to be used as a ThinLTO pass or a LTO pass. It maps each module to a distinct integer, it also generate a mapping file so we can decode the function symbol name from the pair of ids. clang has '-finstrument-function-entry-bare' which inserts a function call and is not as efficient. Three patches are attached, for llvm, clang, and compiler-rt respectively. TODO: (1) Migrate to the new pass manager with a shim for the legacy pass manager. (2) For the order file buffer, consider always emitting def...

...;>>> >>> +1 to -fprofile-instrument=... (as someone working on the XRay stuff, >>> I'd much rather have less flags, and consolidate a lot of these similar >>> things into a more inclusive flag). >>> >>> I would even make it shorter, and say -finstrument={profile-..., >>> xray-...} so we can have multiple "namespaced" values for -finstrument=. >>> >>> Just my A$0.02. >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/...

...question is still opened. May I assume that the following always holds: The first basic block in a function is an entry point and the last basic block in a function is an exit point ? > On 13. Jul 2017, at 10:57, ORiordan, Martin <martin.oriordan at intel.com> wrote: > > The '-finstrument-functions' option may already be sufficient for your needs. > > When selected this inserts the following two calls on entry-to and exit-from a function: > > __cyg_profile_func_enter(void* this_fn, void* call_site) > __cyg_profile_func_exit(void* this_fn, void* call_site) >...

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. Normally this is fine, but with C++ and the heavy use of inline functions and templates, there can be a vast number of trivial functions that are normally...

Hi everyone, I run some functions using ORC JIT, now I need to add custom instrumentation. I want to add two callbacks to each function: ‘enterFunction' at the beginning and ‘leaveFunction' at the end. Intuition says that I could ‘just' insert CallInst's to the first and the last basic blocks in the function. Am I correct? Are there any other/better way to do this? Is there

Hi llvm-dev (cc google-xray), As a follow-up to the first XRay RFC [0] introducing the technology, I've been able to recently implement a functional prototype of the major parts of the XRay functionality [1]. This RFC is limited to exploring potential alternatives to the current LLVM-side changes, with the interest of getting clear guidance for landing the changes first in LLVM. Background /

...ally increase the index. >> >> This pass is intended to be used as a ThinLTO pass or a LTO pass. It maps >> each module to a distinct integer, it also generate a mapping file so we >> can decode the function symbol name from the pair of ids. >> >> clang has '-finstrument-function-entry-bare' which inserts a function >> call and is not as efficient. >> >> Three patches are attached, for llvm, clang, and compiler-rt respectively. >> >> TODO: >> (1) Migrate to the new pass manager with a shim for the legacy pass >> manager...

...Original Message -------- Subject: Re: Adding an attribute to clang Date: Thu, 17 Jun 2010 19:58:51 -0600 From: Sean Hunt <rideau3 at gmail.com> To: cfe-commits at cs.uiuc.edu On 06/17/2010 07:22 PM, Nelson Elhage wrote: > Hi Sean, > > I've been working on a patch to implement -finstrument-functions in > clang, which includes a no_instrument_function attribute. (See [1] for > my earlier patch to LLVM, which Chris Lattner recommended pushing > entirely into clang). When I updated today, I found a conflict with your > attribute work, and saw the comment about not touching A...

...t;>> This pass is intended to be used as a ThinLTO pass or a LTO pass. It >>>> maps each module to a distinct integer, it also generate a mapping file so >>>> we can decode the function symbol name from the pair of ids. >>>> >>>> clang has '-finstrument-function-entry-bare' which inserts a function >>>> call and is not as efficient. >>>> >>>> Three patches are attached, for llvm, clang, and compiler-rt >>>> respectively. >>>> >>>> TODO: >>>> (1) Migrate to the...

On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: >> >>> >>> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at

On Thu, Jun 2, 2016 at 5:30 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Thu, Jun 2, 2016 at 2:51 PM, Frédéric Riss <friss at apple.com> wrote: > >> >> On Jun 2, 2016, at 12:10 AM, Sean Silva <chisophugis at gmail.com> wrote: >> >> >> >> On Wed, Jun 1, 2016 at 5:46 PM, Frédéric Riss <friss at apple.com> wrote: