[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 8:16 AM, Duncan Sands wrote:

> Hi,
>
>>> 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.
>
> maybe those would be cleaned by my globalopt transform :)

Why put this in globalopt?  The form that changes the call is is a  
local/peephole xform, and instcombine is run much more often.

>>> 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 :)
>
> If it is called in several different ways in the same module then  
> indeed
> there's not much you can do.  Still, I can't help feeling this  
> transform
> is useful since I can imagine that quite often people have code in  
> which
> some bogus declaration is used but each call calls it in the  
> "correct" way.

I don't see the compelling reason to do this.  What use case does it  
help?

-Chris