Steve Ellcey writes:
> On Fri, 2013-09-20 at 07:39 +0100, Richard Sandiford wrote:
>> Well, it's really backend code that works out what registers need
>> to be saved and restored, although it's based on generic information.
>> So it should just be a case of making mips_save_reg_p return true for
On Fri, 2013-09-20 at 07:39 +0100, Richard Sandiford wrote:
> Well, it's really backend code that works out what registers need
> to be saved and restored, although it's based on generic information.
> So it should just be a case of making mips_save_reg_p return true for
> all FP registers in an f
On Fri, 2013-09-20 at 07:39 +0100, Richard Sandiford wrote:
> This seems pretty expensive though. Just wondering: is it related to
> the -mfp64 jmp_buf thing?
>
> Thanks,
> Richard
No, this is a separate issue from the -mfp64 jmp_buf bug. We think
there may be some cases where having access to
Steve Ellcey writes:
> I was wondering if someone could help me find the right GCC hooks to
> implement some changes in the prologue and epilogue code for the MIPS
> target. What I am trying to do is to have a flag (call it
> -mfp64-compat) that will allow me to generate code in a routine that
>
On 09/19/2013 04:06 PM, Steve Ellcey wrote:
I was wondering if someone could help me find the right GCC hooks to
implement some changes in the prologue and epilogue code for the MIPS
target. What I am trying to do is to have a flag (call it
-mfp64-compat) that will allow me to generate code in a
I was wondering if someone could help me find the right GCC hooks to
implement some changes in the prologue and epilogue code for the MIPS
target. What I am trying to do is to have a flag (call it
-mfp64-compat) that will allow me to generate code in a routine that
will use the MIPS floating point
