Steve Ellcey <sell...@mips.com> 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 > will use the MIPS floating point unit in fp1 mode (-mfp64, 64 bit > floating point registers) but in a way that is compatible with being > called from a routine in fp0 mode (-mfp32, 32 bit floating point > registers). > > The idea is that the routine is called with the FPU in fp0 mode, then we > save all the floating point registers, because switching modes leaves > the fp registers in an unknown state, and then switch to fp1 mode. At > the return we save the f12 return register (if needed), switch back to > fp0 mode and then restore f12 and the other floating point registers > before the return. I'll leave out the complication of making calls to > other routines from this routine for now. > > I can set TARGET_FLOAT64 at the beginning of the function to generate > fp1 code, but my attempt to create an instruction that switches mode and > clobbers all the floating point registers and calling this from > expand_prologue does not seem to be working. I generate the instruction > (currently just a nop stub) but it does not clobber the floating point > registers. I think this is because expand_prologue is getting called > too late in the rtl expansion/code generation stream. So I am wondering > where I should add this instruction into the rtl stream? Do I need to > create a new rtl pass I could run immediately after the trees are > expanded into rtl? > > I have attached a GCC patch file that I have been experimenting with > so far. If I compile a routine with -mfp64-compat I get my nop > generated by expand_prologue but I do not get the save/restore of the > floating point registers that I was hoping for. If I call > __builtin_mips_switch_fp_mode(0) explicitly then I do see the fp > registers get saved and restored.
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 fp64_compat function. The prologue would then need to restore any incoming float arguments after the mode switch. For something like this you'd also need to define mips_epilogue_uses to return true for all float registers, so that the none of the epilogue restores get deleted as dead later. This seems pretty expensive though. Just wondering: is it related to the -mfp64 jmp_buf thing? Thanks, Richard
