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
