RFC: MIPS paired single vector support

James E Wilson wilson@specifixinc.com
Wed Aug 11 06:07:00 GMT 2004


This is a work in progress.  I am posting this so people can see what
progress I have been making, and so people can comment on the design of
it.  If I need to change something, I'd rather know sooner rather than
later.

There are some ABI issues here.  For parameter passing and function
return values, I am treating the vector values same as doubles.  This is
necessary to get good performance for code using vectors.  I do this
always, even if the target does not have paired single instructions, so
that the ABI is consistent for all targets.  This gives poor code if you
don't have paired single instructions though.

The patch itself should be pretty straight forward.  I added patterns
for all of the paired single instructions in the mips32r2 and mips64
architectures, plus the paired single instruction extensions that are in
the SB-1 processor.

The condition used for the instructions is the same condition used for
the related trunc.l.[sd] instructions, except with ISA_HAS_PAIRED_SINGLE
added.

I added support for vector constants to the 'G' constraint so I could
have a vector 0 handled by CONST_DOUBLE_OK_FOR_LETTER_P.  I am not sure
if that is safe.  I may have to change this.

The compare instructions set two FP condition code registers.  So I
added a CCPSmode that requires two FP cc registers.  The compare stuff
is still unfinished.  I haven't figured out a good way to define builtin
functions for them yet.  I am still playing with this.  We may have to
live with workarounds until we get better vector support from the LNO
branch.

I added builtin functions for all of the paired single instructions that
I couldn't directly generate with C code.  The builtin function names
are pretty stupid at the moment.  I need to come up with better ones.

There are some things that aren't finished yet.  I need to check the
other dfa schedulers and add V2SFmode support as necessary.  I want to
add RTX_COSTS support for the V2SFmode operations.

There are some misc things thrown in because I noticed them while
working on this patch.  const_float_1_operand does more work than
necessary.  I got the mode wrong in the sb1.md file for the DFmode
divide reservation.  I can submit these things separately.

There are also a few unrelated things I have noticed while working on
this patch that I haven't tried to fix yet.  There is no scheduling type
for the recip.fmt instructions, so it gets same schedule as div.fmt,
which kind of defeats the whole purpose of having recip support.  There
is also no RTX_COSTS support for recip insn.

The cmov patterns are noncanonical, they are missing modes on the
comparisons.  I noticed this while stepping through ifcvt.  It tried
generating canonical patterns which did not match, then gives up and
calls emit_conditional_move which calls the cmov* patterns in the md
file which generate the noncanonical patterns.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.paired.single.bz2
Type: application/x-bzip
Size: 8173 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040811/04ace372/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase.c
Type: text/x-c
Size: 3175 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040811/04ace372/attachment-0001.bin>


More information about the Gcc-patches mailing list