search for: transformconstexprcastcall

Displaying 6 results from an estimated 6 matches for "transformconstexprcastcall".

2015 Jan 05
3
[LLVMdev] should AlwaysInliner inline this case?
...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 indeed does, InstCombiner::transformConstExprCastCall. > > I don't have IR to hand, but it would be worth passing your IR through > instcombine to see if that helps you. > The following should be a sufficiently workable example of what we would hope to transform. target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"...
2013 May 30
3
[LLVMdev] Expected behavior of calling bitcasted functions?
...uitofp i32 %call to float store float %1, float* %dest, align 8 ret void } Note the fptoui / uitofp conversions to the underlying function's argument / return type. I would expect this to bitcast the arguments and call the underlying function. This transformation happens in InstCombiner::transformConstExprCastCall. This kind of thing almost seems intentional though from some of the comments and tests, so I'm not sure what's supposed to be going on. A conversion that changes the bits doesn't make any sense to me.
2011 Mar 29
0
[LLVMdev] Anomaly with CallGraph construction
...at the callgraph analysis does 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.
2011 Mar 29
2
[LLVMdev] Anomaly with CallGraph construction
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 =
2015 Jan 05
3
[LLVMdev] should AlwaysInliner inline this case?
Philip, I post here because I think AlwaysInliner should inline it. I want to detect the indirect calls for Inliner, and I want to hear inputs. let me define indirect call first in my idea. In one single expression, one function may be subject to bitcast more than one time. we can detect this situation and treat it as a regular call of last function, is that okay? thanks, --lx On Mon, Jan 5,
2013 May 30
0
[LLVMdev] Expected behavior of calling bitcasted functions?
...at %1, float* %dest, align 8 > ret void > } > > > Note the fptoui / uitofp conversions to the underlying function's argument > / return type. I would expect this to bitcast the arguments and call the > underlying function. This transformation happens in > InstCombiner::transformConstExprCastCall. This kind of thing almost seems > intentional though from some of the comments and tests, so I'm not sure > what's supposed to be going on. A conversion that changes the bits doesn't > make any sense to me. > > _______________________________________________ > LLVM De...