Jeff Law <l...@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
