RE: Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900

[Matthew Fortune <Matthew dot Fortune at imgtec dot com>]

Jeff Law <law@redhat.com> 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
multiplies.

> > 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.

Matthew