[llvm-commits] [llvm] r51134 - in /llvm/trunk: lib/Transforms/Scalar/InstructionCombining.cpp test/Transforms/InstCombine/2003-11-13-ConstExprCastCall.ll test/Transforms/InstCombine/fp-ret-bitcast.ll

[Chris Lattner]

On May 16, 2008, at 7:33 AM, Duncan Sands wrote:

> Hi Chris,
>
>> I'm saying that the optimization is important, and was implemented  
>> for
>> a reason :).  The issue is code like this:
>>
>> --- a.c
>> int foo()
>> int bar() {
>>   return foo(1, 2, 3);
>> }
>> --- b.c
>> void foo(int x, int y, int z) { return x+y+z; }
>>
>>
>>
>> After llvm-link runs, you get the bitcast of function.  It is
>> important to have instcombine squash this so that (e.g.) inline can
>> see a direct call.  However, it should only do this in cases that
>> don't violate the ABI :)
>
> in your example you can see the function definition (and not just
> a declaration), so doing the transform only when you have the
> declaration of the callee to hand would be ok for this example.

Ah right, good call.  For declarations, I think the only cases that  
matter are things like simplifylibcalls, when the libcall didn't have  
the right prototype.  I'm not sure how much this matters.

> PS: I just chucked some code into GlobalOpt that teaches it to change
> the type of a declaration if the only use is a bitcast to a function
> type.  It seems to work!  This transforms the objc testcase to:

The problem is that this objc function can return float, double, and  
long double depend on the callee :)

-Chris