Question about clobbering registers in prologue/epilogue code

[Jeff Law]

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 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.
Can you  open code those saves/restores yourself in 
mips_expand_prologue/mips_expand_epilogue?  At least for a first cut 
that might be easiest.

The register allocator isn't ever going to see the prologue/epilogue 
insns, so if you're depending on it to set regs_ever_live and friends to 
trigger the saves/restores, then it's not going to work.

jeff