similar to: The bit pattern after stripPointerCasts()

> On Dec 14, 2018, at 2:21 PM, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 12/11/18 6:51 PM, Doerfert, Johannes Rudolf via llvm-dev wrote: >> Hi, >> >> in a recent review [0], Florian Hahn helped me to realize something that >> was rather surprising to me: >> >> The widely popular and very useful function

> On Dec 14, 2018, at 2:44 PM, Finkel, Hal J. <hfinkel at anl.gov> wrote: > > Do you have an opinion on which should be the default? > > -Hal > > Not particularly. The current name sounds to me like it would strip any casts it possibly can. Maybe most uses should now be converted to a newly named stripTrivialPointerCasts? -Matt -------------- next part

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: >

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

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

Thanks, Duncan, makes sense! I suppose you meant something like this: Function* callee = dyn_cast<Function>( call->getCalledValue()->stripPointerCasts()); if (!callee) continue; - D. 2012/7/17 Duncan Sands <baldrick at free.fr> > Hi Dmitry, it would be neater to use stripPointerCasts. > > Ciao, Duncan.

(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

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

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 zhangzw, >> invoke void @__cxa_throw(i8* %7, i8* bitcast >> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* >> null) >> noreturn to label %invcont unwind label %lpad > > >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? > > yes! i want get the name @_ZTi or @__cxa_throw, > the latter

On 4/14/11 6:34 PM, Kodakara, Sreekumar V wrote: > > Hi All, > > I have a question on ConstantExpressions and llvm intrinsic > memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C > programs that I am compiling using clang frontend, the call to memcpy > instrinsic looks like the following > > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast

The immediate change I have in mind is in CallGraph; our implementation of LowerCall in AMDGPU currently relies on the the callee arguments being lowered before the call is lowered, and we simply do not support indirect calls. However, we should be able to support these bitcast calls, as they are effectively direct for our purposes, but the CallGraph does not seem to consider them (it uses

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: Instruction *Inst = dyn_cast<Instruction *>(I->getOperand(0)); it gives me a

I'm not sure what the usual "ping time" is for llvm-dev, but may I ask if there are any updates on this? It appears that the following lines are the root cause of the reordering (https://github.com/llvm/llvm-project/blob/fdcb27105537f77c78c4473d4f7c47146ddbab69/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp#L2175): // Handle gep(bitcast x) and gep(gep x, 0, 0, 0). Value

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

On Wed, Jan 16, 2013 at 12:53:55AM +0100, Joerg Sonnenberger wrote: > 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 equal. Let's take the version with the cleanup from IRC. *sigh* Dealing with too many copies. Joerg -------------- next part -------------- Index:

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:

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