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: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "Joseph Myers \(joseph\ at codesourcery dot com\)" <joseph at codesourcery dot com>, "macro\ at codesourcery dot com" <macro 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: Mon, 02 Jun 2014 09:58:41 +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> <6D39441BF12EF246A7ABCE6654B02353545DB2 at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> I've realised that I may need to do 'something' to prevent GCC from loading or
> storing DFmode/DImode values to/from FPRs using pairs of SWC1/LWC1 when using
> an unaligned address. Initial tests show that when loading from an unaligned
> address (4-byte aligned) then GCC loads the two halves of a 64-bit value into
> GPRs and then moves across to FPRs. This is good but I don't know if it is
> guaranteed.
>
> From what I can tell the backend doesn't specifically deal with loading
> unaligned data but rather the normal load/store patterns are used by the
> middle end. As such I'm not sure there is anything to prevent direct loads
> to FPRs by parts.
>
> Do you know one way or the other if unaligned doubles can currently be loaded
> via pairs of lwc1 (same for store) and if so can you advise on an approach I
> could try to prevent this for FPXX? I will try to figure this out on my own in
> the meantime.
The port does handle some widths of unaligned access via the
{insv,extv,extzv}misalign patterns. That's how an unaligned DImode
value will be handled on 64-bit targets.
The MIPS *misalign patterns only handle integer modes, so for other
types of mode the target-independent code will fall back to using an
integer load followed by a subreg (or a subreg followed by an integer
store). IIRC that's how an unaligned DFmode access will be handled on
64-bit targets.
For modes that are larger or smaller than *misalign can handle,
the target-independent code has to split the access up into smaller
pieces and reassemble them. And these pieces have to have integer modes.
E.g. on 32-bit targets a 4-byte-misaligned load into (reg:DF x) could be
done by loading (subreg:SI (reg:DF x) 0) and (subreg:SI (reg:DF x) 4).
The thing that prevents these individual loads from using LWC1 is
CANNOT_CHANGE_MODE_CLASS, which (among other things) makes it invalid
for any target-independent code to reduce a subreg of an FPR pair
to an individual FPR.
[FWIW, the reason MIPS doesn't define {insv,extv,extzv}misalign for things
like DImode on 32-bit targets is because there's no special architecture
feature than can be used. It's just a case of decomposing the access.
Since that's a general technique, we want to make the target-independent
code do it as well as possible rather than handle it in a port-specific way.]
So yeah, the combination of (a) STRICT_ALIGNMENT, (b) the lack of unaligned
floating-point load/store patterns and (c) CANNOT_CHANGE_MODE_CLASS should
guarantee what you want.
Thanks,
Richard