similar to: [LLVMdev] dyn_cast<Instruction *> returns NULL where it should return a valid instruction

On 5/16/11 9:35 AM, Chuck Zhao wrote: > I have the following prototype for a function: > void bkp_memory(char *, int); > > Inside my LLVM IR, I have a callsite looks like the following: > tail call void @bkp_memory(i8* bitcast (i32** @P to i8*), i32 4) nounwind > > > When I try to obtain its 1st argument and check whether it is a valid > instruction, using: >

While working on my optimization pass (a Function Pass), I try to replicate a call instruction and insert it at some earlier location (similar to LICM). However, the instruction I am trying to replicate has dependencies on an uncertain number of instructions that are used to generate an address. A simple example (IR segment): define void @foo() nounwind { entry: %a = alloca i32, align 4;

Dear Chuck, I haven't read all of the details, but it seems that what you need to do is to clone defs before you clone any uses of the def. To do that, you want to iterate over the instructions in dominator-tree order. To do that, you first construct the dominator tree (there is an LLVM analysis pass that does that). Then, you iterate over the basic blocks in the dominator tree from

I collected a sequence of LLVM instructions, want to make a copy of each and insert them into a PREVIOUS location inside the same function (all globals and locals are properly declared before the PREVIOUS location). Here is the list of instructions I want to duplicate and insert: 0 %90 = load i32* @strstart, align 4 1 %91 = add i32 %90, 2 2 %88 = load i32* @ins_h, align 4 3 %92 =

Hello, This patch fixes PR2218. However, I'm not pretty sure that this optimization should be in MemCpyOpt. I think that GVN is good place as well. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218.patch Type: application/octet-stream Size: 6146 bytes Desc: not available URL:

On Jul 22, 2009, at 1:37 PM, Jakub Staszak wrote: > Hello, > > This patch fixes PR2218. Very nice. Are you sure this fixes PR2218? The example there doesn't have any loads in it. > However, I'm not pretty sure that this optimization should be in > MemCpyOpt. I think that GVN is good place as well. Yes, you're right. My long term goal is to merge the relevant

Hello, Sorry for my stupid mistakes. I hope that everything is fine now. This patch fixes PR2218. There are no loads in example, however "instcombine" changes memcpy() into store/load. Regards, Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218-2.patch Type: application/octet-stream Size: 6525 bytes Desc: not available URL:

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc:

Hi Tim, I'm still struggling on the instruction: call void bitcast (void (%struct.png_struct_def.68*, i8*, i8* (%struct.png_struct_def.68*, i64)*, void (%struct.png_struct_def.68*, i8*)*)* @png_set_mem_fn to void (%struct.png_struct_def*, i8*, i8* (%struct.png_struct_def*, i64)*, void (%struct.png_struct_def*, i8*)*)*)(%struct.png_struct_def* %create_struct, i8* %mem_ptr, i8*

On Jul 25, 2009, at 4:48 PM, Jakub Staszak wrote: > Hello, > > Sorry for my stupid mistakes. I hope that everything is fine now. > This patch fixes PR2218. There are no loads in example, however > "instcombine" changes memcpy() into store/load. Hi Jakub, Sorry for the delay, I'm way behind on code review. Generally if you respond quickly, I'll remember

Hi All, I am facing an issue with CallInst with nested bitcast instruction. I want to check if the return type of a call is void or non-void the below line works well for CallInst without bit cast. *cast<CallInst>(I)->getCalledFunction()->getReturnType()->isVoidTy()* But for Call instructions like *call void bitcast (void (%struct.jpeg_compress_struct.131*, i32)*

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote: > The bug here isn't in clang's use of noalias or in BasicAliasAnalysis' > implementation of noalias; it's in the code that's optimizing the > icmp. Let's come back to this. The attached patch decouples InstSimplify from the alias analysis and provides the conservative logic for when pointers are not

My pass is looking at StoreInsts acting on global variable that happen to be function pointers. From these StoreInsts I would like to get useful information(the function used if a direct assignment, function pointer used, etc) from the getValueOperand() method. Looking through several examples I see that this can return several things like: GlobalVariable, Function, LoadInst or BitCastInst

OK, at our end the following workaround seems to be sufficient: // Check if function is called (needs -instcombine pass). Function* callee = call->getCalledFunction(); if (!callee) { // Could be also a function called inside a bitcast. // So try to extract function

On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the

Hi Chuck, > std::vector<Instruction *>::iterator p; > Instruction * pi = PREVIOUS_POSITION; > BasicBlock * pb = PREVIOUS_POSITION->getParent(); > > for(p = coll.begin(); p != coll.end(); ++p){ > Instruction * CurI = * p; > Instruction * CloneI = CurI->clone(); clone doesn't know have any magical way of knowing that it should update the instruction's

On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: > > Is that > > assumption violated if I explicitly cast away const and pass the result > > to a function with NoAlias argument? > > Not immediately, no. It means that you can't access the constant > pointer's pointee directly within the noalias argument's scope. Access > to that object must go

Hi Dmitry, it would be neater to use stripPointerCasts. Ciao, Duncan. > OK, at our end the following workaround seems to be sufficient: > > // Check if function is called (needs -instcombine pass). > Function* callee = call->getCalledFunction(); > if (!callee) > { >

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was

(Moving to LLVM-dev). I hope thats ok to just move the conversation over from commits. To summarise, selection DAG crashes if personality functions are not actually functions. This conversation is to try work out if that is a restriction we want to document in LangRef, or (as David B suggests), we should allow opaque values to be personality functions. I don’t actually know EH code at all, so