[llvm-commits] [llvm-gcc-4.2] r48608 - in /llvm-gcc-4.2/trunk/gcc: config/i386/llvm-i386-target.h config/i386/llvm-i386.cpp config/rs6000/llvm-rs6000.cpp config/rs6000/rs6000.h llvm-abi.h llvm-convert.cpp

[Dale Johannesen]

On Mar 31, 2008, at 4:44 AM, Duncan Sands wrote:

> Hi Dale,
>
>>> Hi Dale, I've cleaned up the return value part
>>> in commit 48778.  Can you please check that it
>>> works properly for you.  I haven't yet decided
>>> the best way of handling the argument case.
>>
>> There are some regressions but they all appear to be a different
>> problem.  We'll need to get that cleaned up to be sure.
>
> while cleaning up the call argument part, I discovered an existing  
> bug.
> Compiling SingleSource/UnitTests/Vector/SSE/sse.isamax.c on x86-32  
> linux
> gives the assertion
>
>  cc1: Instructions.cpp:258: void llvm::CallInst::init(llvm::Value*,  
> llvm::Value* const*, unsigned int): Assertion `(NumParams == FTy- 
> >getNumParams() || (FTy->isVarArg() && NumParams > FTy- 
> >getNumParams())) && "Calling a function with bad signature!"' failed.
>
> The reason is that @llvm.x86.sse.movmsk.ps is declared as
>
>  declare i32 @llvm.x86.sse.movmsk.ps(<4 x float>) nounwind readnone
>
> but the vector is being passed in integer registers in the call,  
> namely
> as two i64's.

This works on darwin (<4 x float> is used consistently).    
llvm_x86_should_pass_vector_in_integer_regs is all dependent on  
TARGET_MACHO and presumably shouldn't be, but it may not be as simple  
as removing TARGET_MACHO.