SH patch applied (Was: Re: sh64 support deteriorating)

[Joern RENNECKE]

Kaz Kojima wrote:

>  
>
>some compile time errors in c/c++ test for sh64-unknown-linux-elf
>http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00466.html
>
>3 tests
>
>gcc.c-torture/compile/simd-4.c
>gcc.c-torture/execute/20050604-1.c
>gcc.dg/torture/pr21817-1.c
>
>fail with the similar ICE:
>
>gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c: In function 'tempf':
>gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: unable to find a register to spill in class 'GENERAL_REGS'
>gcc/gcc/testsuite/gcc.c-torture/compile/simd-4.c:15: error: this is the insn:
>(insn 53 52 54 0 (set (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
>        (and:DI (subreg:DI (reg:V4SF 68 fr4 [196]) 0)
>            (const_int -4294967296 [0xffffffff00000000]))) 85 {anddi3} (nil)
>    (nil))
>  
>
Yes, these appeared also in the simulator tests.

>It seems odd that the DImode subregs of V4SFmode registers are used
>as the operands of logical operations, though I don't understand why
>reload complains as above.
>  
>
reload complained because HARD_REGNO_MODE_OK disallowed
V4SFmode in GENERAL_REGS.  Allowing that also causes register
allocation to use GENERAL_REGS in the first place.  An and with a
J16 constraint can also be done with FP_REGS using mov.ls from r63.
A natural way to implement this would use an fr (or rf) constraint in
one of the alternatives.  While looking at this I also found that we were
missing a register class for an fr constraint.  I've tested the attached
patch over the weekend for sh-elf and sh64-elf, and checked it in now.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tmp
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050912/266b1d5f/attachment.ksh>