search for: instcombinecalls

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. Converting to a store will make program pass Silently. This changes the behavior of a program. So we need remove the case if (isa<ConstantPointerNull>(Callee) at InstCombi...

...nswers. 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 getPromotedType(...) cd ../../../build/ make ONLY_TOOLS="lli" error: llvm[3]: Compiling InstCombineCalls.cpp for Debug+Asserts build /home/beckert/workspace/llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp: In function ‘l...

> 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

..., the combine fails because InstCombine queries CastInst::isBitCastable to determine the castable-ness of the parameter type and the argument type. It isn't bitcastable though, it's ptrtoint/inttoptr castable. The following patch opens up the optimization: --- a/lib/Transforms/InstCombine/InstCombineCalls.cpp +++ b/lib/Transforms/InstCombine/InstCombineCalls.cpp @@ -1456,7 +1456,7 @@ bool InstCombiner::transformConstExprCastCall(CallSite CS) { Type *ParamTy = FT->getParamType(i); Type *ActTy = (*AI)->getType(); - if (!CastInst::isBitCastable(ActTy, ParamTy)) + if (!CastInst::i...

...in Ma; 'llvmdev Dev' Subject: Re: [LLVMdev] Should remove calling NULL pointer or not 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. Converting to a store will make program pass Silently. This changes the behavior of a program. So we need remove the case if (isa<ConstantPointerNull>(Callee) at InstCombi...

...39;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 <Matthew.Arsenault at amd.com> wrote: > On 11/05/2014 02:04 PM, Dingbao Xie wrote: > > The documentation of LLVM says that "The llvm.objectsize intrinsic is > lowered to a constant representing the size of the object co...

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. Converting to a store will make program pass > > Silently. This changes the behavior of a program. > > So we need remove the case if (isa<ConstantPointerNul...

...on what a general policy might look like. Philip On 11/6/13 4: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. Converting to a store will make program pass > > Silently. This changes the behavior of a program. > > So we need remove the case if (isa<ConstantPointerNul...

...ling NULL pointer or not > > > > 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. Converting to a store will make program pass > > Silently. This changes the behavior of a program. > > > > So we need remove the case if (isa&l...

...re 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 "if this is target specific, call into the target specific library". See below for a patch that starts to go in that direction by making it easier to tell between generic and target specific intrinsics. The othe...

...t 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 behavior of the program is undefined. So the behavior is correctly defined, as emphasised by the check in ``InstCombineCalls`` that turns mismatching convention into an ``undef``. This is however very error-prone. Maybe we should either: - update the API to enforce the CC when building a ``CallInst`` - update LangRef to state that mismatching CC in static call is an error (note that LangRef is unclear about static c...

The documentation of LLVM says that "The llvm.objectsize intrinsic is lowered to a constant representing the size of the object concerned". I'm attempting to lower this intrinsic function to a constant in a pass. Below is the code snippet that I wrote: for (BasicBlock::iterator i = b.begin(), ie = b.end(); (i != ie) && (block_split == false);) { IntrinsicInst *ii =

...not try to understand indirect calls like this is that other passes are supposed to sort such things out if they can be sorted out. If they failed then there is no point in having the callgraph analysis try too. The main place that tries to sort out such bitcasts is transformConstExprCastCall in InstCombineCalls.cpp. You may want to rummage around in there to work out why it thinks removing the bitcast is unsafe. So the answers to your questions are: (1) yes, and (2) it is not a job for the analysis - instcombine is the place to take care of this. Ciao, Duncan.

...g loads and stores undecorated, meaning optimization of such instructions cannot benefit from TBAA. Furthermore, our analysis indicates that the only place where !tbaa.struct tags may potentially impact code generation is simplification of memcpy() and memmove() calls, see SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what the code that makes that sole use of such tags is trying to do is to construct a !tbaa tag from the information encoded in the given !tbaa.struct tag. Note that it can only do that if the !tbaa.struct tag describes a structure with a single member of a scalar type. Here's...

Hi all, I have been trying to build a loop nesting analysis which works interprocedurally. In order to find the functions called inside a given loop, I am traversing the Instructions into the BasicBlock's that conform a Loop, and applying the code that CallGraph construction uses: ------ extract from CallGraph.cpp : 144 // Look for calls by this function. for (Function::iterator BB =

Hi, I am working on a pass to convert lib calls to intrinsic calls as discussed here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058507.html In my first attempt I created a FunctionPass that uses CallInst::setCalledFunction to replace the callee with the appropriate intrinsic (using Intrinsic::getDeclaration). After the pass runs I get an assertion from CallGraphSCCPass:

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

...e? LTO, Value optimizations, mem ?? You'd have to implement explicit support for the new intrinsics in various places. For value optimization, I imagine you'll want to add support to both lib/Analysis/ConstantFolding.cpp (for when all arguments are constants) and lib/Transforms/InstCombine/InstCombineCalls.cpp (for when at least one isn't). LTO support would be automatic since I can't really imagine -instcombine not running during LTO (unless perhaps inlining is disabled, in which case it probably won't matter anyway), and that's just one of the passes that try to constant fold instr...

...hat is essential for that purpose? > >  -Hal > >> >> Furthermore, our analysis indicates that the only place where >> !tbaa.struct tags may potentially impact code generation is >> simplification of memcpy() and memmove() calls, see >> SimplifyMemTransfer() in InstCombineCalls.cpp. Ironically, what >> the code that makes that sole use of such tags is trying to do is >> to construct a !tbaa tag from the information encoded in the >> given !tbaa.struct tag. Note that it can only do that if the >> !tbaa.struct tag describes a structure with a single...

Consider the following IR example: define void @simple([4 x double] *%ptr, i64 %idx) { %stack = alloca [4 x double] %ptri8 = bitcast [4 x double] *%ptr to i8* %stacki8 = bitcast [4 x double] *%stack to i8* call void @llvm.memcpy.p0i8.p0i8.i32(i8 *%stacki8, i8 *%ptri8, i32 32, i32 0, i1 0) %dataptr = getelementptr inbounds [4 x double], [4 x double] *%ptr, i32 0, i64 %idx