[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900
From:       Woon yung Liu <ysai187 () yahoo ! com>
Date:       2016-02-27 6:38:23
Message-ID: 689234744.126560.1456555103234.JavaMail.yahoo () mail ! yahoo ! com
[Download RAW message or body]

Hi all,

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

I noticed that GCC has a movmemsi pattern. If I couldn't implement full support for \
the MMI, it would be great if the quad-word load and store instructions could be used \
to improve memory-copying performance.

Unfortunately, as much as I tried, I couldn't get mips_block_move_straight to use the \
lq/sq instructions. It seems like the RTL patterns are not unique according to their \
names, but the inputs/outputs. Hence why GCC seems to always default to using the \
default move instruction (which eventually calls mips_output_move).

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

 
If I consolidated the lq/sq instructions into a single insn pattern (mem to mem), \
then GCC will correctly output the lq/sq instructions. However, that doesn't result \
in interleaved loads and stores, so I don't think that performance will be too good. \
For example: lq $a2, 80($v0)

sq $a2, 80($v1)
lq $a2, 90($v0)
sq $a2, 90($v1)

If this isn't the problem that I think it is, could somebody please advice me on how \
to get this to work?


Thanks and regards,
-W Y


[prev in list] [next in list] [prev in thread] [next in thread]