similar to: RFC: Comprehensive Static Instrumentation

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

Hey Mehdi, Thank you for your comments. I've CC'd the CSI mailing list with your comments and put my responses inline. Please let me know any other questions you have. Cheers, TB On Thu, Jun 16, 2016 at 3:48 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Jun 16, 2016, at 9:01 AM, TB Schardl via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >

Hey David, Thank you for your feedback. I'm trying to understand the model you sketched in order to compare it to CSI's current approach, but the details of your proposal are still fuzzy to me. In particular, although the model you described would avoid using LTO to elide unused hooks, it seems more complicated for both tool writers and tool users to use. Please clarify your model and

On Thu, Jun 16, 2016 at 3:27 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi TB, > > Thanks for you answer. > > On Jun 16, 2016, at 2:50 PM, TB Schardl <neboat at mit.edu> wrote: > > Hey Mehdi, > > Thank you for your comments. I've CC'd the CSI mailing list with your > comments and put my responses inline. Please let me

On 6/16/2016 2:48 PM, Mehdi Amini via llvm-dev wrote: > >> On Jun 16, 2016, at 9:01 AM, TB Schardl via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> The CSI framework inserts instrumentation hooks at salient locations >> throughout the compiled code of a program-under-test, such as >> function entry

Hey Peter and David, Thank you for your comments. As mentioned elsewhere, the current design of CSI does not rely on LTO for correctness. The tool-instrumented executable will run correctly even if the linker performs no optimization. In particular, unused instrumentation hooks are implemented by default as nop functions, which just return immediately. CSI is a system that *can use* LTO to

We've just released the project code for public review. You can find the diffs at the following links: CSI LLVM pass: http://reviews.llvm.org/D21445 CSI Clang support: http://reviews.llvm.org/D21446 CSI Runtime and tests: http://reviews.llvm.org/D21447 The RST for the CSI project can be found with the Clang diff. We know that this code requires changes, additions, more tests, cleanup, etc.

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

On Fri, Jun 17, 2016 at 5:42 AM Matthias Braun via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Some of this overlaps with the features in XRay ( > http://lists.llvm.org/pipermail/llvm-dev/2016-April/098901.html). > > Matthias beat me to it! >From reading the RFC, it seems that some of what XRay is doing on the instrumentation side is very similar to what CSI enables. The

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 /

Hi All, Our team at Facebook is building a new context-sensitive Sample PGO as an alternative to the existing AutoFDO. We’d like to share our motivation, propose a new design, and reveal preliminary results on benchmarks. We will refer to the proposed design as CSSPGO in this RFC. The new CSSPGO leverages simultaneous LBR and stack sampling to construct a full context-sensitive profile. It

Yes, zlib build for LTO will work, but user will have to build this lib from zlib source code anyway. On Fri, Sep 23, 2016 at 4:01 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Sep 23, 2016, at 1:44 PM, Vitaly Buka via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Is it possible to add zlib source code into llvm repo? Any advice on how

FYI, The LLVM Performance Workshop will be held at CGO 2017. The workshop is co-located with CC, HPCA, and PPoPP. If you are interested in attending the workshop, please register at the CGO website: http://cgo.org/cgo2017/workshops.html When: Saturday February 4th, 2017 Where: Austin, Texas, USA ---- Hi, CGO workshop and tutorial organizers, This is a friendly reminder that early

See my answers inline. From: Xinliang David Li <davidxl at google.com> Date: Friday, August 7, 2020 at 7:57 PM To: Wenlei He <wenlei at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi <wmi at google.com>, Hongtao Yu <hoy at fb.com> Subject: Re: [RFC] Context-sensitive Sample PGO with Pseudo-Instrumentation On Fri, Aug 7,

Hello, I am developing an LTO instrumentation of programs for fuzzing (for afl++) and I run into the following problem: a lot of open source program have multiple definitons of the same functions. In normal compile mode this is not a problem, however with LTO this only works with the linker option: -Wl,--allow-multiple-definition Now to be able to instrument (it is an "opt"

Hello, even though the study of Intel MPX took much longer than expected, we have finally finished it. Currently, it is published in two formats: * as a technical report: https://arxiv.org/abs/1702.00719 * and as a webpage: https://intel-mpx.github.io/ This work contains evaluation of MPX from perspectives of performance (Phoenix, PARSEC, and SPEC benchmark suites), security (RIPE and found

Thanks for the thoughtful questions, David. See my answers inline. Thanks, Wenlei From: Xinliang David Li <davidxl at google.com> Date: Friday, August 7, 2020 at 1:24 PM To: Wenlei He <wenlei at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, Wei Mi <wmi at google.com>, Hongtao Yu <hoy at fb.com> Subject: Re: [RFC] Context-sensitive

> 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

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 optimised away; but with the instrumentation hooks

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