This is the mail archive of the
mailing list for the GCC project.
RE: Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Jeff Law <law at redhat dot com>, Woon yung Liu <ysai187 at yahoo dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 19 Jan 2016 15:02:59 +0000
- Subject: RE: Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900
- Authentication-results: sourceware.org; auth=none
- References: <1133386899 dot 5784392 dot 1453192585066 dot JavaMail dot yahoo dot ref at mail dot yahoo dot com> <1133386899 dot 5784392 dot 1453192585066 dot JavaMail dot yahoo at mail dot yahoo dot com> <2139471769 dot 5822207 dot 1453204744040 dot JavaMail dot yahoo at mail dot yahoo dot com> <569E4B61 dot 7020101 at redhat dot com>
Jeff Law <firstname.lastname@example.org> writes:
> On 01/19/2016 04:59 AM, Woon yung Liu wrote:
> > In my current attempt at adding support for the TI mode, the MMI
> > definitions are added into a MD file for the R5900 and some functions
> > (i.e. mips_output_move) were modified to allow certain moves for the
> > TI mode of the R5900 target. However, while it seems like TI-mode
> > integers can now be passed between functions and used with the MMI
> > (within one 128-bit GPR), GCC still treats 128-bit moves as complex
> > moves (split across two 64-bit registers); its built-in functions
> > expect both $a0 and $a1 to be used if the first argument is a 128-bit
> > value. To return a 128-bit value, both $v0 and $v1 are used.
> You'll have to adjust FUNCTION_ARG and its counterpart for return values
> to describe how to pass these 128 bit values around.
I'm generally against modified calling conventions especially given the
number of them that MIPS already has. We opted against using new wider
registers for arguments/returns in MSA instead choosing to consider it
as an optimised convention rather than the standard.
What environment are you looking to support this in? Linux, bare metal,
BSD, other? There's a reasonable amount of housekeeping to consider for
context switching and debug depending on the environment.
On the topic of TImode... Do you ever truly end up with TImode data with
the R5900 extensions or is it all vector types? We initially had TImode
in various places for MSA and removed it all in favour of the vector
modes which made everything a lot cleaner. If there truly is TImode
support then things get a little ugly based on what I remember from
untangling MSA from TImode mainly because of the interaction with
> > Otherwise, I believe that there are two solutions to the problem with
> > the calling convention (but again, I have no idea which is better):
> > 1. Keep the target as 64-bit. Support for MMI will be either
> > compromised (i.e. made to assemble and split the 128-bit vectors upon
> > entry/exit) or totally omitted. Perhaps omission would be best so that
> > there will never be a compromise in performance.
As above I suggest this approach but allow vectors to be passed using
the pre-existing defacto convention and look at optimizing it later.