X86: when SSE1 isn't available, f32 arguments are incorrectly passes as f64

[llvmbot]

Bugzilla Link	1489
Resolution	FIXED
Resolved on	Feb 22, 2010 12:41
Version	1.0
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

llvm-gcc is miscompiling the following c code:

---

#define _ISOC9X_SOURCE 1
#include <math.h>
int main( void ) { return (lrintf(3.999f) > 0)?0:1; }

---

laurov@laurov-laptop:/tmp$ gcc test.c -o test -lm
laurov@laurov-laptop:/tmp$ ./test
laurov@laurov-laptop:/tmp$ echo $?
0
laurov@laurov-laptop:/tmp$ llvm-gcc test.c -o test -lm
laurov@laurov-laptop:/tmp$ ./test
laurov@laurov-laptop:/tmp$ echo $?
1

To reproduce this bug with llc must be used "llc -disable-fp-elim -fast -mcpu=i486".

[llvmbot]

It is passing a 64-bit value for the 32-bit float, obviously wrong. It does not do this without -mcpu=i486.

[lattner]

Very interesting. Investigating.

[lattner]

Okay, the problem here is simple enough. f32 is not a legal datatype when you don't have SSE, so the call
argument is promoted from f32 to f64 (which is what the codegen thinks x87 FP registers are).

This obviously loses important information for the call, but it seems like we need to extend the ISD::CALL
node to represent this somehow. Dale, Evan, any thoughts?

[llvmbot]

Perhaps change such parameters to bitcast to i32. That's sort of what's going on in a calling convention
where arguments are passed uniformly on stack or in int registers.

[lattner]

Yep, that sounds like a good plan Dale. Can you please do this? It'll be in the ISD::CALL handling code of
Legalize, if you have any q's, please let me know.

-Chris

[llvmbot]

That'll teach me to comment.
OK.

[lattner]

:) It's a good chance to get exposure to the legalizer :)

[llvmbot]

Yeah, I know. Forgot a smiley I guess.

[llvmbot]

Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070604/050332.html

[llvmbot]

The fix above was removed in favor of:
http://llvm.org/viewvc/llvm-project?view=revision&revision=37847