similar to: [LLVMdev] Inlining bitcast functions...

On Fri, Nov 9, 2012 at 3:25 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > I've got a call instruction: > call void bitcast (void (%4 addrspace(1)*, <2 x i32>, <4 x float>)* @_Z12write_imagefPU3AS110_image2d_tDv2_iDv4_f to void (%9 addrspace(1)*, <2 x i32>, <4 x float>)*)(%9 addrspace(1)* %dstimg, <2 x i32> %28, <4 x float> %26)

Eli, Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) opaque types as different, since it really has no way to know if the caller and the callee really are referring to the same thing… though it then seems to turn right around and do exactly that by inserting the bitcast. ;-) (That does come from the linker.) That the linker 'works

Spoke too soon... running the inst combine pass does seem to resolve the linker/inlining issue. But the resulting code fails to run correctly. I was expecting the same result that I get when running with unstripped modules, that is passing test runs. When it still failed, I guessed the failure mode to be the same, but it isn't. Not sure WHAT to make of this...

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

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.

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, I'm trying to write a small piece of code that inlines all calls to a particular function. The codes is as follows Function* klee_check_divF = module->getFunction("klee_div_zero_check"); assert(klee_check_divF != 0 && "Failed to find klee_div_zero_check function"); // Hack inline checks for (Module::iterator f = module->begin(), fe =

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

Hi. I have a test program: class A { int A; public: virtual void test ( int x ) = 0; }; class B : public A { int B; public: void test ( int x ) {}; }; int main() { A *a = new B(); a->test(1); } We have call site CS: "a->test(1);". CS.getCalledFunction() - return NULL, so we can say that this call site is virtual. My optimization determines, that in this call site

You are probably calling setName() on the called Function, which in-turned renamed the called Function instead of replacing the called function. Depending on your use-case, if you are certain that you only need to modify CallInsts, then you could simply call CallInst::setCalledFunction , otherwise it’s probably wiser to use CallSite as a wrapper for both CallInst and InvokeInst. Do note, however,

On Fri, Nov 9, 2012 at 3:58 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > Eli, > Thanks. I don't think it's a bug in the linker, really… it's required to treat (stripped) opaque types as different, since it really has no way to know if the caller and the callee really are referring to the same thing… though it then seems to turn right around and do exactly that

We have a function that has 256 loads and 256 fmuladds. This block of operations is bounded at either end by an OpenCL barrier (an AMDIL fence instruction). The loads and multiply/adds are ordinarily interleaved... that is, the IR going in to code generation looks like: %39 = load float addrspace(3)* getelementptr inbounds ([16 x [17 x float]] addrspace(3)* @sgemm.b, i32 0, i32 0, i32 0), align

> I'll look in to instcombine, but if you've got any further words of advice on how to use it, they would be greatly appreciated. It's a pass; you run it. No joy running the instcombine pass between the link and my inlining code... still a call to a bitcast.

thanks! After I check the ll file, I find this: %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048 %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg !2048 %3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0, !dbg !2048 %4 = load i32 (...)*** %3, align 4, !dbg !2048 %5 = getelementptr inbounds i32 (...)** %4, i32 10, !dbg !2048 %6 = load i32 (...)**

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 1/26/11 2:07 PM, songlh at cs.wisc.edu wrote: > Hi: > > My llvm code is: > > for( BasicBlock::iterator i = b->begin() , ie = b->end(); > b != be ; b ++ ){ > if( CallInst * pCall = dyn_cast<CallInst>(i)){ > > pCall->dump(); // > Function * pFunction = pCall->getCalledFunction(); > if(

On May 26, 2009, at 3:15 PM, Jeffrey Yasskin wrote: > In Unladen Swallow we (intend to) compile each function as we > determine it's hot. To "compile" a function means to translate it from > CPython bytecode to LLVM IR, optimize the IR using a > FunctionPassManager, and JIT the IR to machine code. We'd like to > include inlining among our optimizations. Currently

> On 1/26/11 2:40 PM, songlh at cs.wisc.edu wrote: >> thanks! >> >> After I check the ll file, I find this: >> >> %1 = load %struct.nsAString** %aBuf_addr, align 4, !dbg !2048 >> %2 = getelementptr inbounds %struct.nsAString* %1, i32 0, i32 0, !dbg >> !2048 >> %3 = getelementptr inbounds %struct.nsISupports* %2, i32 0, i32 0, !dbg >> !2048

On 12/17/2013 11:29 AM, reed kotler wrote: > I have a pass which operates on IR for mips16 so that I can build stubs > and such for floating point. > > I usually get this attribute of the call instruction getCalledFunction. > > This is turning out to be null when there is a tail call. (I think this > may be something new but maybe was there already). > > So then what is

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