Re: PATCH for PR6445

[Mark Mitchell <mark at codesourcery dot com>]

--On Thursday, April 25, 2002 11:12:32 AM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Thu, Apr 25, 2002 at 10:56:12AM -0700, Mark Mitchell wrote:
>> I think this is the obvious patch, but a confirmation from an x86 back
>> end expert would be helpful.  Maybe it would be better to deal with
>> this in override_options?
>
> Except that -msoft-float -mfp-ret-in-387 is useful in that it is ABI
> compatible with -mhard-float code, assuming an fpu emulator in the OS,
> yet performs most of its operations directly in software rather than
> trapping.
>
> This has been this way long enough that there might well be folks
> depending on it.  Especially since -msoft-float -mno-fp-ret-in-387
> works for those folks that _don't_ have an fpu emulator.

That makes some sense.

But, we still have the __builtin_apply problem.  And since that appears
in the Objective C library, that means you can't do Objective C with
-msoft-float -mfp-ret-in-387.

The problem is that to deal with __builtin_apply, we basically need
to be able to copy from the return registers, and we can't because
we don't have floating point support.  One approach would be to say
that "Well, if you have -mfp-ret-in-386, you must have kernel support
for FP, so we'll just generate the instruction, and you can just emulate
it."

I've attempted that with this patch.  It seems to work OK for the test
case; I'm a little nervous about allowing FP insns in the middle of
the code -- I'm not sure if we'll get burned by not having disabled
patterns in i386.c.

Thoughts?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index: i386.md
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.md,v
retrieving revision 1.339.2.6
diff -c -p -r1.339.2.6 i386.md
*** i386.md	20 Apr 2002 00:24:50 -0000	1.339.2.6
--- i386.md	25 Apr 2002 19:00:13 -0000
***************
*** 13694,13705 ****
       simply pretend the untyped call returns a complex long double
       value.  */

!   emit_call_insn (TARGET_80387
!                   ? gen_call_value (gen_rtx_REG (XCmode, FIRST_FLOAT_REG),
! 				    operands[0], const0_rtx,
! 				    GEN_INT (SSE_REGPARM_MAX - 1))
!                   : gen_call (operands[0], const0_rtx,
! 			      GEN_INT (SSE_REGPARM_MAX - 1)));

    for (i = 0; i < XVECLEN (operands[2], 0); i++)
      {
--- 13694,13702 ----
       simply pretend the untyped call returns a complex long double
       value.  */

!   emit_call_insn (gen_call_value (gen_rtx_REG (XCmode, FIRST_FLOAT_REG),
!                                   operands[0], const0_rtx,
!                                   GEN_INT (SSE_REGPARM_MAX - 1)));

    for (i = 0; i < XVECLEN (operands[2], 0); i++)
      {