similar to: [LLVMdev] Accessing slot numbers of unnamed instructions (SlotTracker)

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() <<

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

<please email llvmdev, not me directly> On Dec 7, 2009, at 8:47 AM, Florian Merz wrote: > Hi Chris, > > I do understand that you don't want to keep the whole history, but > to me > personally a simple line for recent changes like "introduced in 2.7" > or > "removed in 2.7" would have been nice, so this might be the case for > other >

Hi everyone, I noticed that MallocInst and FreeInst have been removed from the LLVM IR as well as the language reference[1]. May I propose that at least some placeholder is left in that document telling the reader that these instructions have been removed. This should be kept in at least until there is one official release that does not support these instructions anymore. The same goes for

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

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 oggen*8.ll, the compile time is reduced from

I am trying to parse LLVM IR from a bit code file. I went through the following steps. hello.cpp #include <iostream> int main() { std::cout << "Hello world!" << "\n"; return 0;} dump.cpp #include <llvm/IR/Module.h>#include <llvm/IRReader/IRReader.h>#include <llvm/IR/LLVMContext.h>#include <llvm/Support/SourceMgr.h> using

Hi, I have: ... @.str1 = private unnamed_addr constant [21 x i8] c"Now f is a function\0A\00", align 1 ; Function Attrs: ssp uwtable define i32 @_Z1fv() #2 { entry: %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([21 x i8]* @.str1, i32 0, i32 0)) ret i32 0 } Then I get after trying to erase the function from the module: 511

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

On 23 October 2013 22:41, Vassil Vassilev <vvasilev at cern.ch> wrote: > Hi, > I have: > ... > @.str1 = private unnamed_addr constant [21 x i8] c"Now f is a > function\0A\00", align 1 > ; Function Attrs: ssp uwtable > define i32 @_Z1fv() #2 { > entry: > %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([21 x > i8]* @.str1, i32 0,

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

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

Hi, I am writing a new transformation (Basic block pass). In the "\llvm-2.5\lib\VMCore\AsmWriter.cpp " file there are some of function i want to use. What do i need to add to the transformation code, so i will be able to use those functions? I tried to use a function and got this error : 'AssemblyWriter' was not declared in this scope. Thanks. -------------- next part

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 have the following simple IR: define i32 @squak(i32 %num) #0 { %1 = alloca i32, align 4 store i32 %num, i32* %1, align 4 %2 = load i32, i32* %1, align 4 %3 = icmp sgt i32 %2, 10 I’m grabbing the predicate of “icmp”, which in this case is a simple

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 *

Hi all, I am currently struggling with an odd sieve/Pigeonhole issue. Some weeks ago I had to replace our dovecot certificate due to expiration. In the past I did use a self-signed certificate, but because we now have a little openssl based CA I have decided to create signed certificate for imaps. Dovecot is happily accepting the new certificate which has integrated the whole cert-chain.

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

I fell over this issue yesterday myself with lots of asserts being thrown. I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function AssemblyWriter::printFunction(const Function *F) Looking at the code I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

Hi! I'm looking for a way to make the the "llc" tool (or any other tool), directly produce a binary file for some target. The TargetMachine class has a method 'addPassesToEmitMachineCode', that's suitable for that, but that method also requires an instance of MachineCodeEmitter. The existing MachineCodeEmitter derived classes are either debug-only (writing to