similar to: Avoiding during my pass the optimization (copy propagation) of my LLVM IR code (at generation)

> On Dec 30, 2016, at 3:03 PM, Alex Susu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello. > I'm writing an LLVM pass that is working on LLVM IR. > To my surprise the following LLVM pass code generates optimized code - it does copy propagation on it. It does *constant* propagation to be exact. > Value *vecShuffleOnePtr = Builder.CreateGEP(ptr_B,

Hello. I'm getting the following error after adding some extra instrumentation in a module (LoopVectorize.cpp ) due to a bug in Value::replaceAllUsesWith (see more comments of mine below): Value::replaceAllUsesWith(New = i16* inttoptr (i16 51 to i16*)), this = %VectorGep = getelementptr i16, i16* inttoptr (i16 51 to i16*), <128 x i64> zeroinitializer, !dbg !17 ; this

In a code segment of my pass plugin, I try to gather AliasSets for all StoreInst, LoadInst and CallInst instructions in a function. Some behaviors of the pass puzzled me. Below is the *.ll of the test program which I run the pass on, it was get with "llvm-gcc -Wl,--disable-opt" from a rather simple *.c program. ---------------------------------- ; ModuleID = 'ptralias.bc'

Oh, I appologize that I should not have asked about __main() ---- it appears in FAQ. But the question remains that why call to __main() can alias stack location? I think the memory location pointed by data_X pointers are not visible to __main(). In comparison, calls to printf() do not have similar effect. On 5/14/06, Nai Xia <nelson.xia at gmail.com> wrote: > > In a code segment of

Hi Chris, I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis and SteensGaard.cpp in LLVM this afternoon. So I think: 1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions. 2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as an

On Tuesday 16 May 2006 03:19, Chris Lattner wrote: > On Mon, 15 May 2006, Nai Xia wrote: > > > In other words, if I only use -steens-aa and the data_XXXs are all > > external global variables( and so inComplete ), > > Sounds right! > > > the call to printf will > > make the same effect, which I have tested it. > > > > Am I right ? :) >

On 18 Oct 2015, at 23:08, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Supporting only basic block level granularity for "try ranges" may not > be sufficient for Java -- if a basic block has more than one null check > in it then throwing the NullPtrException for the first null check (if > it fails) is semantically different from throwing the

On Wed, 17 May 2006, Nai Xia wrote: > Unfortunately, I did not locate the lines in steens-aa for "printf" special case. > In ds-aa, I found the lines below: Right, steens-aa and ds-aa share code for "local analysis", they just stitch it together into an interprocedural analysis in different ways. The code below is used for steens-aa. >

On Mon, 15 May 2006, Nai Xia wrote: > In other words, if I only use -steens-aa and the data_XXXs are all > external global variables( and so inComplete ), Sounds right! > the call to printf will > make the same effect, which I have tested it. > > Am I right ? :) If you've tested it then, yes you're right :). I haven't played with this stuff for a long time,

I won’t be able to attend, but I’d be interested in hearing if any conclusions are reached on several of these topics: > On 16 Oct 2015, at 21:27, Joe Ranieri via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > - Dealing with the explosion of basic blocks that come up with > languages where almost every function call, implicit and explicit, can > raise exceptions. This

On Fri, Jul 15, 2016 at 2:30 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > However, I didn't quite understand your point about may-throw -- how > > is may-throw different from a generic side-effect (volatile store, > > syscall etc.)? All of those can't be hoisted or sunk -- we have to >

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > Don't we have the same problems for "exit(0)" > > > > > > This is a noreturn call, so yes, iit has another hidden control > > flow-side-effect of a slightly different kind. GCC models it as an extra >

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Dear all, 1) I have a very large matrix of  str(keep)  num [1:153899, 1:3415] -98.6 -95.8 -96.4 -95.8 -98 ... that  I would like to reduce its size to something like str(keep)  num [1:1000, 1:3415] -98.6 -95.8 -96.4 -95.8 -98 ...  or anything similar in size as this is a matrix that needs plotting (so is ok if it is 1000 row, 995, or 1123) I think what I need here is a way of selecting

Hi, I'm having a hard time finding an answer to what I assume is a very basic idea. I'm trying to produce this llvm code using the LLVM api: %myString = alloca [13 x i8], i32 13 store [13 x i8] c"Hello world.\00", [13 x i8]* %myString %tmp1 = getelementptr [13 x i8]* %myString, i32 0, i32 0 %tmp2 = call i32 (i8*, ...)* @printf( i8* %tmp1 ) nounwind A simple Hello

Hello, I am writing an LLVM backend that generates byte code for a custom virtual machine. Standard function calls are lowered to a simple CALL $offsetInByteCode This works fine so far using the standard machinery of LLVM. But some functions are not implemented in byte code, but delegated to native implementations within the VM. Calls to these functions use a non-standard calling convention

I notice that there's a lot of inconsistency in the various LLVM classes with respect to convenience methods. Here's some examples: For creating GEPS, IRBuilder has: CreateGEP (2 overloads) CreateInBoundsGEP (2 overloads) CreateConstGEP1_32 CreateConstInBoundsGEP1_32 CreateConstGEP2_32 CreateConstInBoundsGEP2_32 CreateConstGEP1_64 CreateConstInBoundsGEP1_64

These were requested by Bill Wendling to simplify a Mips 16 clang change. The test is in the code in Clang which uses these for mips 16. -------------- next part -------------- Index: include/llvm/IR/Function.h =================================================================== --- include/llvm/IR/Function.h (revision 176874) +++ include/llvm/IR/Function.h (working copy) @@ -181,6 +181,14 @@