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: Richard Henderson <rth at redhat dot com>
- To: Woon yung Liu <ysai187 at yahoo dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Sat, 5 Mar 2016 14:28:56 -0500
- Subject: Re: Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900
- Authentication-results: sourceware.org; auth=none
- References: <569E4B61 dot 7020101 at redhat dot com> <2072261853 dot 5954977 dot 1453221016992 dot JavaMail dot yahoo at mail dot yahoo dot com> <689234744 dot 126560 dot 1456555103234 dot JavaMail dot yahoo at mail dot yahoo dot com>
On 02/27/2016 01:38 AM, Woon yung Liu wrote:
I've given up on trying to implement MMI support for this target because I
couldn't get the larger-than-normal GPR sizes to work nicely with the GCC
internals (registers sometimes get split due to the defined word size, or the
stuff in expr.c will just suffer from assertion failures).
[ Apologies for assumptions being made here, since I can't find an instruction
set reference for the r5900 anymore. ]
You probably don't want to be using TImode for MMI support anyway, since, in
the broader context this instruction set extension is about SIMD.
Thus e.g. V16QImode and V8HImode might be more appropriate.
It seems like the RTL patterns are not unique according to their names, but
Is there a way to force GCC to use a specific pattern (i.e.
"r5900_qword_store" and "r5900_qword_load")? I don't want to add the lq/sq
instructions to mips_output_move because it will allow lq/sq to be used for
stuff that isn't supported (i.e. loading TI-mode data types into a register for
arithmetic operations that don't exist).
You can't. For a given set of inputs, one must provide all of the valid ways
that one can perform the operation as alternatives.
Thus for TImode move, currently defined as
[(set (match_operand:TI 0 "nonimmediate_operand" "=d,d,d,m,*a,*a,*d")
(match_operand:TI 1 "move_operand" "d,i,m,dJ,*J,*d,*a"))]
one would have to add additional alternatives for the lq and sq instructions
(and probably a register-register alternative as well, e.g. por d,s,s).
You must use the set_attr section to describe when the alternatives that you
add are valid. The "enabled" attribute controls this. Looking at the mips
port, it would appear that adding to "move_type" would be best.
It is of course simpler if the patterns that you want to add do not overlap
with existing patterns. Thus if you stick to the vector modes you have less
overlap than if you describe MMI as using TImode.