similar to: [LLVMdev] Should remove calling NULL pointer or not

I've definitely seen code like the following in various production code bases: namespace { bool global = false; } class Foo { void modify_global() { global = true; } }; // usually, there's a layer of indirection (or two, or three) here ((Foo*)NULL)->modify_global(); Discussions on StackOverflow seem to clearly indicate that the above code is undefined. Having said that, I

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu] Sent: Wednesday,

On 11/6/13 6:36 PM, Yin Ma wrote: > > Hi, > > For a small case, that calls NULL pointer function. LLVM explicitly > converts > > It to a store because it thinks it is not reachable like calling > undefvalue. > > In InstCombineCalls.cpp:930 > > I think it is not a right approach because calling null pointer function > > Will segfault the program.

On Thu, Nov 7, 2013 at 11:02 AM, Yin Ma <yinma at codeaurora.org> wrote: > Hi John, > > > > It seems the dereferencing a NULL pointer is undefined behavior but > > Calling a function through a null pointer seems o.k. > What is the well defined behavior of calling a null function pointer? > > > If so , for this place, we need comment out the check. >

I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >

Is copy.0 semantically equivalent to copy.1 in the following example? define void @copy.0(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) { entry: %val = load i8 addrspace(1)* addrspace(1)* %src store i8 addrspace(1)* %val, i8 addrspace(1)* addrspace(1)* %dst ret void } define void @copy.1(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst)

I am writing some code to identify malloc instructions with constant request sizes and to determine the request size if it is constant. I have two questions. 1) If a malloc is for an array allocation and the array size is a ConstantExpr, how can I obtain the value of the ConstantExpr? 2) I am using the following logic to determine if the malloc is for a constant request size and to

On Mon, Jan 5, 2015 at 1:40 AM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi lx, Philip > > I've seen an instcombine which helps with this situation. It fires when > the function types on both sides of the bitcast have the same number of > operands and compatible types. It then adds bitcasts on the arguments and > removes the one on the called function. > It

Ryan M. Lefever wrote: > I am writing some code to identify malloc instructions with constant > request sizes and to determine the request size if it is constant. I > have two questions. > > 1) If a malloc is for an array allocation and the array size is a > ConstantExpr, how can I obtain the value of the ConstantExpr? > The only way I know of is to determine what type

Thanks for your reply. I'm attempting to expand KLEE to support this intrinsic function. That's why I need to handle this myself. According to the reply, the correct implementation should first find the definition of the object and then determine the size of the object. BTW, can I just refer to the implementation in InstCombineCalls.cpp. On Wed, Nov 5, 2014 at 2:24 PM, Matt Arsenault

Hi llvm-dev, Every now and then, when building a direct ``CallInst`` either from IRBuilder or through ``Create*``, I have a latent bug because the calling convention (CC) expected by the function is not set on the call, and I need to manually call ``setCallingConv``. Now, from LangRef#calling-conventions, The calling convention of any pair of dynamic caller/callee must match, or the

There are a few places in llvm's generic codegen that refer to target specific intrinsics. This is bad layering and we shouldn't do it. It also means that if we don't build a target we still have to support all of it's intrinsics and other such annoyances. The main violator of this is InstCombineCalls - I'd like to push this into the targets, and just have a case that says

Hi Gabriel, ... > Summarizing, I have two questions: 1) is the CallGraph analysis "working as > intended" here?; and 2) what would be the correct approach > to modifying the proposed analysis in order to detect that randlc() is being > called in that CallInst ? the reason that the callgraph analysis does not try to understand indirect calls like this is that other passes

Dear LLVM developers, I have a question regarding the IPSCCP class and the handling of dead blocks: The file lib/Transforms/Scalar/SCCP.cpp of llvm 2.8 from contains some code to deal with a dead block which could not be folded (line 1909ff). This happens when a user of this dead block is a branch or switch with an undef condition. The action taken than is to replace this terminator with an

Hi, thanks for your answers. I did: cd workspace svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/ mkdir build cd build/ ../configure --enable-jit make                                                      # OK, everything went fine. cd ../lib/Transforms/InstCombine/            # Just to test vim InstCombineCalls.cpp                       # added `if (0 == 1) return 0;` at

Hello, The motivation behind this proposal is to make it possible to propagate TBAA information through scalarizing transformations, such as SROA, that rewrite accesses to aggregates, e.g., memcpy() calls, into accesses to scalars, that is, load and store instructions. Currently, we decorate instructions that initialize and copy aggregates with !tbaa.struct tags that generally cannot be

> Neither worked. =( Hmm. Something seems to have gone horribly wrong then. I've just reproduced Peter's suggestion on the autoconf build and it worked fine. Perhaps try a clean build out of tree: CMake: mkdir my_special_build_dir cd my_special_build_dir cmake $PATH_TO_LLVM_SOURCE make llc Autotools: mkdir my_special_build_dir cd my_special_build_dir $PATH_TO_LLVM_SOURCE/configure

On Fri, 4 Apr 2008, David Greene wrote: > I am confused by this bit of code in instcombine: > > 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { > 09790 const Value *GEPI0 = GEPI->getOperand(0); > 09791 // TODO: Consider a target hook for valid address spaces for this > xform. > 09792 if (isa<ConstantPointerNull>(GEPI0)

Dan Gohman wrote: > Hello, > > On Nov 4, 2009, at 1:51 AM, Hans Wennborg wrote: >> >> / Hans >> Index: lib/Analysis/BasicAliasAnalysis.cpp >> =================================================================== >> --- lib/Analysis/BasicAliasAnalysis.cpp (revision 86023) >> +++ lib/Analysis/BasicAliasAnalysis.cpp (working copy) >> @@ -633,6 +633,15