This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Richard Sandiford <rdsandiford at googlemail dot com>, "Joseph Myers (joseph at codesourcery dot com)" <joseph at codesourcery dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, "'gcc-patches at gcc dot gnu dot org' (gcc-patches at gcc dot gnu dot org)" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 22 May 2014 17:43:57 +0100
- Subject: RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B023535233AE at LEMAIL01 dot le dot imgtec dot org> <87r43qlshb dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B02353539412 at LEMAIL01 dot le dot imgtec dot org> <87ha4ihjhk dot fsf at talisman dot default> <6D39441BF12EF246A7ABCE6654B0235353B386 at LEMAIL01 dot le dot imgtec dot org>
On Thu, 22 May 2014, Matthew Fortune wrote:
> GCC is saving too much of the callee-saved registers when single-precision
> values are live in them but this is historic behaviour. The code which
> controls this is very complex and I'd be worried about breaking it. The
> fix would be invasive as all the logic is honed towards the notion of
> 64-bit callee-saved registers. One thing to say is that this test is
> a very aggressive test of ABI not normal compiler behaviour. Normally
> an even-numbered callee-saved register would be used first followed by the
> odd meaning that it is rare to only use the odd register. That flips the
> problem round to single precision data in even registers...
>
> I believe that prior to mips32 introducing odd-numbered single-precision
> registers then GCC will have been saving and restoring using sdc1/ldc1
> for even-numbered registers regardless of whether they are used for
> single or double precision data (for mips1 it also will do pairs of
> lwc1/swc1).
This is required by the architecture, on legacy MIPS processors any
arithmetic operation writing to a single floating-point (S format) or a
single fixed-point (W format) destination is specified to leave the upper
32 bits of the destination in an undefined state. Depending on the FPU
implementation and the state of the CP0 Status.FR bit (when implemented)
the upper 32 bits are located in either the upper half of the 64-bit FPR
selected or the odd-numbered 32-bit FPR corresponding to the even-numbered
FPR selected. See the StoreFPR pseudocode in the R4400 processor manual
or other legacy MIPS documentation that you undoubtedly have handy.
So while making changes in this area you need to take care to retain
saving/restoring full double FPRs on pre MIPS32/MIPS64 processors as their
upper halves may be clobbered even if only single operations are used.
Maciej