similar to: Handling argument for an intrinsic

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

Hi llvm-dev, I'm trying to reproduce an msan failure in one of the bots, but I can't seem to get the right incantation of building LLVM with msan. Here's what I've been doing: 1) Build the toolchain in one build directory, including `compiler-rt`. 2) Build the toolchain again with the just built toolchain in step 1, but this time with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`. I

Another option is just to run corresponding script from *https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/ <https://llvm.org/svn/llvm-project/zorg/trunk/zorg/buildbot/builders/sanitizers/>* in empty directory. On Thu, Aug 30, 2018 at 5:00 AM Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Dean, > > I've not done this

Aside: would it be useful to execute a build of the libc++/libc++abi with msan normally during release, and change the driver to look for these msan-built C++ libs when "-fsanitize=memory"? That would drastically cut down on the complexity of using msan. On Fri, Aug 31, 2018 at 5:43 AM Dean Michael Berris via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks Vitaly and

# Objective Implement an XRay mode 'xray-profiling' that gathers stack trace latencies/durations and builds histograms to provide basic statistics about where time is going in an execution of the application. # Background XRay has two modes currently implemented in compiler-rt: a basic (nee naive) mode and flight data recorder (FDR) mode. Basic mode logging, when enabled, will collect

FYI: Patch is now available for review in https://reviews.llvm.org/D44620. On Thu, Feb 15, 2018 at 1:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > # Objective > > Implement an XRay mode 'xray-profiling' that gathers stack trace > latencies/durations and builds histograms to provide basic statistics about > where time is going in an execution of the

On Mon, Jan 7, 2019 at 3:21 PM Dean Michael Berris <dean.berris at gmail.com> wrote: > On Mon, Jan 7, 2019 at 8:43 PM Dangeti Tharun kumar > <cs15mtech11002 at iith.ac.in> wrote: > > > > Hi Dean, > > > > I have tried with -instr-map-1 and -instr-map-2, it didn't work. > > > > Yeah, I'm looking through the code and it looks like

Hi all, I was interested in trying out the Xray profiling component in LLVM and was trying to compile a C program with Clang with Xray flags. Unfortunately, I keep getting a linker error everytime I try to compile the C program with Clang. However, the error goes away when I try to compile the same C program with Clang++ with -xc++ flag. Searching around for this issue, looks like somebody has

Hi llvm-dev, I've been implementing a tool for analysing XRay traces. A recap of XRay's original RFC [0] mentions a tool that does function call accounting as a starting point. This is implemented currently in D21987 [1], and is being reviewed by David Blaikie. One key issue in that review is the dependency between the log format determined by the XRay runtime implementation in

Hi Dean, I haven't looked very closely at XRay so far, but I'm wondering if making CTF (common trace format, e.g. see http://diamon.org/ctf/) the default format for XRay traces would be useful? It seems it'd be nice to be able to reuse some of the tools that already exist for CTF, such as a graphical viewer (http://tracecompass.org/) or a converter library

Hi, The call graphs generated by "*llvm-xray graph*" has function names, while the "*llvm-xray graph-diff*" doesn't shows function names. This is the command I am using llvm-xray graph-diff xray-log.clang.1 xray-log.clang.2 -instr-map=../xray-build/bin/clang -o diff.dot Attached is the portion of the generated diff graph. Am I missing any flag? [image: graph_diff.jpg]

I see. Thanks for clarifying. I'm Ok with merging these if Dean agrees, as I believe he's the code owner. Thanks, Hans On Thu, Jan 26, 2017 at 11:47 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > There were no LLVM tests for presence of XRay instrumentation map in the > emitted assembly. You can see that https://reviews.llvm.org/D28624 adds this > check to the

Hi llvm-dev, Recently, we've committed the beginnings of the llvm-xray [0] tool which allows for conveniently working with both XRay-instrumented libraries as well as XRay trace/log files. In the course of the review for the conversion tool [1] which turns a binary/raw XRay log file into YAML for human consumption purposes, a question arose as to how we intend to allow users to develop tools

I'm wondering why the lit tests didn't catch this as part of testing rc1 on ARM. On Thu, Jan 26, 2017 at 11:25 AM, Serge Rogatch <serge.rogatch at gmail.com> wrote: > XRay is tested automatically on build-bots with tests in LLVM and > compiler-rt . Or are you asking for manual testing instructions? > Of these 2 patches, the compiler-rt patch depends on LLVM patch because

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, I am trying to add XRay support to the IR produced by GHC. Getting the basics working is not too complicated after adding the right function attribute but any analysis shows the function names but not the locations of the functions. In particular, I run a program which has been instrumented as follows: XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./llvm

Hi Dean/Serge, I just spotted this on our bots: First failure, unrelated commit: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/3190 'XRay-Unit :: unit/XRayFDRLoggingTest/FDRLoggingTest.Simple' FAILED llvm/projects/compiler-rt/lib/xray/tests/unit/fdr_logging_test.cc:55: Failure Expected: FDRLogging_init(kBufferSize, kBufferMax, &Options,

Hi Dean, For me the build is still broken: -- Builtin supported architectures: i386;x86_64;x86_64h CMake Error at projects/compiler-rt/lib/xray/tests/CMakeLists.txt:21 (add_library): add_library cannot create target "RTXRay.test.osx" because another target with the same name already exists. The existing target is a static library created in source directory