[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

[Dale Johannesen]

On May 14, 2008, at 11:22 PM, Duncan Sands wrote:

> Hi Bill,
>
>> Situations can arise when you have a function called that returns a  
>> 'void', but
>> is bitcast to return a floating point value. The result of the  
>> instruction may
>> not be used by the program afterwards, and LLVM will happily remove  
>> all
>> instructions except the call. But, on some platforms, if a value is  
>> returned as
>> a floating point, it may need to be removed from the stack (like  
>> x87). Thus, we
>> can't get rid of the bitcast even if there isn't a use of the value.
>
> I don't get it.  Running the testcase under instcombine without your  
> changes
> turns
>
> %tmp107 = call float bitcast (void (%struct.NSObject*, ...)*  
> @objc_msgSend_fpret to float (%struct.NSObject*,  
> %struct.objc_selector*)*)( %struct.NSObject* %tmp106,  
> %struct.objc_selector* %tmp105 ) nounwind              ; <float>  
> [#uses=0]
>
> into
>
>        call void (%struct.NSObject*, ...)*  
> @objc_msgSend_fpret( %struct.NSObject* %tmp106,  
> %struct.objc_selector* %tmp105 ) nounwind
>
> Since there is now no floating point value returned, how can there  
> be a problem with
> removing it from the stack?  So I don't understand what this change  
> is fixing.

objc_msgSend_fpret does in fact return a floating point value on the  
x87 stack (despite its quaint typing as "void").
Failure to pop this leads to stack overflow.