similar to: Back tracing Variables

Hi Juan: I haven't looked at SlotTracker, but have been using MemoryDependenceWrapperPass to do something similar. hth... don On Fri, Dec 23, 2016 at 5:55 AM, Juan Ceasar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Good Morning - Happy Holidays everyone! > > I had a question about the best way to do back tracing of variables via > the IR. So for example, if I

Hey everyone, I'm currently trying to figure out a method for providing a unique identification of an llvm::Instruction that is consistent with the output of an AssemblyWriter. Obviously this is easy for named instructions: In this case the identification is the name itself, but I'd like to have the same thing for unnamed instructions. If I understand the code in AssemblyWriter.cpp

Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry

On Friday 13 November 2009 15:17, you wrote: > > Are these known to be broken right now? I get failure when using either. > > > > $ llc -march=arm -print-machineinstrs hw.bc > > Seems due to David's patches. Ok, it's faulting in SlotTracker with what looks like a bad Function. One of the Argument values is corrupted. I'm not abdicating responsibility, but at

Kostya, I took a quick stab at patching libFuzzer for Apple, but so far I'm thinking something else is incorrect. Patch is attached but when I went to reproduce the examples, the toy example went fine, but with PCRE and Heartbleed I noticed the coverage statistics were pretty poor, and didn't find anything. Admittedly I moved onto Heartbleed pretty quickly so PCRE probably isn't the

You can get the name of a variable by using the method getName() of llvm::Value. However it returns a blank string if the variable is a numbered variable, such as %11. How can I make it return %11 in such case. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130222/d6d434e8/attachment.html>

FWIW see also http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043301.html As far as I understand DFSan functionality isn't required for libFuzzer to work, so it should be safe to disable DFSan support on Mac. On Wed, Jul 8, 2015 at 7:45 AM, Kostya Serebryany <kcc at google.com> wrote: > +pcc , glider > > On Mon, Jul 6, 2015 at 12:59 PM, Juan Ceasar <juan.d.ceasar at

Hi, The attached is the OCaml binding patch to 2.6. This still works on 2.6, because the optimizations I am working on rely on some features of 2.6, which were removed from 2.7. But from the view of OCaml bindings, it does not change too much from 2.6 to 2.7, I also merged some new bindings in 2.7 into 2.6. What this patch does are 1) bindings to define an LLVM IR pretty printer in OCaml, which

So I was curious to start using the libFuzzer, but trying to follow along I got the following error: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned long, unsigned long, unsigned long long, unsigned long

On Nov 13, 2009, at 1:49 PM, David Greene wrote: > On Friday 13 November 2009 15:17, you wrote: >>> Are these known to be broken right now? I get failure when using either. >>> >>> $ llc -march=arm -print-machineinstrs hw.bc >> >> Seems due to David's patches. > > Ok, it's faulting in SlotTracker with what looks like a bad Function. One

Are these known to be broken right now? I get failure when using either. $ llc -march=arm -print-machineinstrs hw.bc ... BB#0: derived from LLVM BB %entry Live Ins: %LR %R7 %SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0 STR %LR<kill>, %SP, %reg0, 4, 14, %reg0; mem:ST4[0 llc 0x008b3304 PrintStackTrace(void*) + 45 1 llc 0x008b390c

Afternoon, I had an issue with trying to link a program with the DataFlowSanitizer functionality, this is from the libFuzzer project, and I was seeing: clang++ -fsanitize=address -fsanitize-coverage=edge test_fuzzer.cc Fuzzer*.o Undefined symbols for architecture x86_64: "_dfsan_create_label", referenced from: fuzzer::TraceState::DFSanCmpCallback(unsigned long, unsigned

Tobi, it looks like this code is the problem: for (std::vector<Value *>::iterator PI = Pointers.begin(), PE = Pointers.end(); ;) { Value *V = *PI; if (V->getName().size() == 0) OS << "\"" << *V << "\""; else OS << "\"" << V->getName() <<

hi Sean Silva: i really appriciate for your reply. but you konw that "dump()" instruction can print "%4" in the screen and each time print the same name "%4" not "%5" or "%6" for the same unnamed value. so there must be a way to determinate it. if "dump()" instruction can print it on the screen, can i find some way to store it in a char *

At 2013-07-14 13:20:42,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/13/2013 09:18 PM, Star Tan wrote: >> >> >> At 2013-07-14 02:30:07,"Tobias Grosser" <tobias at grosser.es> wrote: >>> On 07/13/2013 10:13 AM, Star Tan wrote: >>>> Hi Tobias, >>> >>> Hi Star, >[...] >>> Before we write a

Hi to all. I upgraded my dovecot from rc5 to rc6. Prior to upgrading, it was working seamlessly. But now I couldn't start dovecot. Here's what the log says: Aug 10 10:39:17 proxy dovecot: Dovecot v1.0.rc6 starting up Aug 10 10:39:18 proxy dovecot: Login process died too early - shutting down Aug 10 10:39:18 proxy dovecot: child 29033 (login) killed with signal 11 Aug 10 10:39:18 proxy

Hi All, I’m being a complete newbie on this one but how do I generate the OCaml bindings? I saw an old google post using “configure —enable-bindings=ocaml” but we don’t use configure anymore (I’m building 3.9.1) and if I just do a regular build (optimized) then I don’t see any bindings in my build directory…. Any ideas? JC

Hi Sebastian, Yes, you have pointed an important reason. If we comment this source code you have listed, then the compile-time overhead for oggenc*8.ll can be reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). I just sent another mail to explain why polly-detect pass leads to significant compile-time overhead. Besides the reason you have pointed, another reason is resulted from those string

On 07/14/2013 08:05 AM, Star Tan wrote: > I have found that the extremely expensive compile-time overhead comes from the string buffer operation for "INVALID" MACRO in the polly-detect pass. > Attached is a hack patch file that simply remove the string buffer operation. This patch file can significantly reduce compile-time overhead when compiling big source code. For example, for

How can I get the name of the virtual Registers present on an instruction. eg. %add18 = add nsw i32 %mul17, %37 in this case I want to extract the name of the virutal registers as "add18", "mul17","37". This can easily be done in the case of store Instruction eg. store i32 %add20, i32* %t, align 4 in this case functions like