This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]