[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 15, 2008, at 1:29 PM, Dale Johannesen wrote:

>
> On May 15, 2008, at 1:24 PM, Duncan Sands wrote:
>
>> Hi Dale,
>>
>>>> are you saying that the declaration of objc_msgSend_fpret is wrong?
>>>> That sounds like the real problem to me.  Having wrong declarations
>>>> is fatal.  For example, suppose that the declaration was right: it
>>>> does return void.  Then NOT performing the transform would be  
>>>> wrong,
>>>> because otherwise you will pop a float that shouldn't be popped...
>>>> Where is the declaration coming from?
>>>
>>> That's the way the ObjC FE does things; it predates anyone working  
>>> on
>>> llvm, and has tendrils all over gcc.  I don't like it either.  In
>>> theory I think you are right, but I doubt changing that is a
>>> practical
>>> approach.
>>
>> I feel your pain :)  Nonetheless, it would be better to fix this in
>> the
>> front-end if possible.  Did you/Bill try and fail?
>
> Not really.  But we, and Chris, have tried to change some of the other
> weird things the ObjC FE does and always wound up having to back it  
> out.

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.

One issue with objc_msgSend_fpret is that it is implemented in  
assembly, and thus has some magic semantics.  I don't think there is  
an easy way to fix this in the frontend.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20080515/36f3190d/attachment.html>