On 19/01/16 14:42, Jeff Law wrote: > 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. > >> >> >> 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. > >> >> 2. Promote the word size of the R5900 to 128-bit. I think that SONY >> might have done this, as the code from their late games used lq/sq >> (quard-word load/store) to preserve registers. However, I think that >> this goes against the existing ABIs, doesn't it? Plus the MMI >> instruction set is proprietary and isn't used in any other MIPS. > Changing the word size to 128 bit should not be necessary. > > Many ports define patterns for operations on data types that are larger > than their native word mode. > > You really need to add the new patterns for operating on 128bit values > to the machine description and adjust the parameter passing routines . > > We did have to force the compiler to assume a 64bit *host* datatype > (long long). I don't recall the reasoning behind that. >
Probably because historically you needed CONST_DOUBLE (with VOIDmode) to handle 128-bit immediates (a pair of HOST_WIDE_INTs). It may not be necessary any more with the new wide integer types. R. > >> If I carry on with my current design, I suppose that I need to make >> it so that the hi1/lo1 registers are never used for other MIPS >> targets. I didn't find a RTL constraint that meant something like >> "nothing", so I made the new constraints define MD1_REGS (hi1/lo1) as >> their MD_REGS (hi/lo) equivalents if the target is not the R5900 >> (much like the DSP ACC register constraint, ka). But unlike the DSP >> ACC register constraint (ka), my constraints are used as alternatives >> alongside whatever (i.e. x for hi/lo or ka for hi/lo/acc) that was >> originally there. Would this be acceptable, given that there will be >> two similar alternatives for some instructions when the target is not >> the R5900? > You define the registers & constraints normally. However, you make the > registers conditional on the target in use. ie, if you're not on an > r5900 target, then mark those registers as fixed. That will prevent the > compiler from trying to use them on things other than the r5900. > > Again, you may want to find the old cygnus releases of the r5900 > toolchain. It had functional access to the second hi/lo register pair. > > jeff >
