[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 4:57 AM, Duncan Sands wrote:

>>>> In this case, the ObjC front-end is doing something bizarre, but  
>>>> ok.
>>>> The issue here is that LLVM should be ok in the face of  
>>>> declarations
>>>> that don't match their definitions.  If we just see a call to a  
>>>> cast
>>>> of a declaration, we shouldn't change the call (which determines  
>>>> the
>>>> ABI) just because of a declaration. If the callee was a cast of a
>>>> definition, changing it would be ok.
>>>
>>> then isn't the correct fix to not do this transformation at all
>>> (including
>>> transforming parameters) unless the definition is available?
>>
>> The important case for this xform is for making varargs arguments
>> explicit, as when you forget to use a prototype in C.
>
> Not sure if you are agreeing or disagreeing here!  Also, it might
> be nice to do the following transform: if all uses of a function
> declaration are bitcasts to some function type, change the type
> of the declaration to that function type.

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

-Chris