RFA: Add support for Renesas RX architectiure to GCC

[Richard Henderson]

On 10/05/2009 08:06 AM, Nick Clifton wrote:
> -m64bit-doubles -ffast-math is allowed, but it will not use RX FP
> instructions. The FX FP instructions only support a 32-bit long doubles
> and since Renesas did not ask us to provide a 64-bit support using
> 32-bit FP instructions I did not implement it.

I'm not asking you to provide 64-bit support using 32-bit FP 
instructions, I'm asking you to provide 32-bit support using 32-bit FP 
instructions.  I.e. code compiled with -m64bit-doubles -ffast-math and 
using "float" will use the hardware instructions.

>> Why are you hiding the register affected?
>
> Because the registers concerned are those being pushed or popped and if
> I use the the actual register RTXes they can become renumbered. For
> example I tried switching the patterns to use "register_operand"
> constraints and newlib fails to build because the cprop_hardreg pass
> replaces:
>
> (parallel [(set (reg/f:SI r0)(plus:SI (reg/f:SI r0)(const_int 32)))
> (unspec_volatile [(reg:SI 6 r6)] 0)
> (unspec_volatile [(reg:SI 13 r13)] 1)])
>
> with:
>
> (parallel [(set (reg/f:SI r0)(plus:SI (reg/f:SI r0)(const_int 32)))
> (unspec_volatile [(reg:SI 6 r6)] 0)
> (unspec_volatile [(reg:SI 3 r3 [13])] 1)])
>
> which is completely bogus.

For the parallel push/pop, you'll have to use a match_parallel 
predicate, similar to the s390 "load_multiple_[sd]i" patterns.

For the single push/pop, you should not have to do anything special.

>> Why the last alternative? Can't reload figure out it should use the
>> first alternative?
>
> Not in the tests that I ran. :-( This was a month or so ago, so maybe
> reload has improved since then, but I figured that leaving it in would
> not hurt.

I won't press the point, but I'd really like to know what went wrong.

>> Here and with the other string patterns, I think you'd do well to load
>> up all of the operands into pseudos and move them to hard registers
>> immediately before the string instructions. That might minimize the
>> lifetime of the hard registers and prevent some cases of spill failures.
>
> I thought that I was doing that already.

No, you were computing each operand and moving into a hard register 
immediately.

> I have had a couple of goes at this so far but not had much success. I
> would prefer to leave these patterns as they are for now and revisit
> them later.

Ok.

> Because I could not get reload to play nicely with them without the
> unspec_volatile.

I'm surprised about that.  Aside from the fact that any of the builtins 
that touches the cc0 register can't actually work, I'd like to see an 
example that fails with just unspec.

I presume at some point you'll add DImode add and subtract patterns? 
They should be trivial to implement with adc/sbb instructions.



r~