Supporting FP cmp lib routines

Supporting FP cmp lib routines

[Mohamed Shafi]

Hi all,

I am doing a GCC port for a 32bit target in GCC 4.4.0. The target uses
hand coded floating point compare routines. Generally the function
returns the values in the general purpose registers. But these fp cmp
routines return the result in the Status Register itself.  So there is
no need to have compare instruction after the function call for FP
compare. Is there a way to let GCC know that the result for FP compare
are stored in the Status Register so that GCC generates directly a
jump operation? How can i implement this?

Regards,
Shafi

Re: Supporting FP cmp lib routines

[Richard Henderson]

On 09/14/2009 06:59 AM, Mohamed Shafi wrote:
> Is there a way to let GCC know that the result for FP compare
> are stored in the Status Register so that GCC generates directly a
> jump operation? How can i implement this?

There is no way to do this via the standard libcall sequence.

In order to implement this, you'll want to build the function
calls yourself, directly from the cbranch expanders.  Have a
look at alpha_emit_xfloating_libcall for ideas.

You'll want to make sure that that your status register is set
up as the return value of the call pattern, i.e.

   (set (reg:CC status-reg)
        (call:CC (mem (symbol_ref "fp-compare-routine"))))


That should be about all you need to get things working.


r~

Re: Supporting FP cmp lib routines

[Richard Henderson]

Another thing to look at, since you have hand-written routines and may 
be able to specify that e.g. only a subset of the normal call clobbered 
registers are actually modified, is to leave the call as a "compare" 
insn.  Something like

(define_insn "*cmpsf"
   [(set (reg:CC status-reg)
         (compare:CC
           (match_operand:SF 0 "register_operand" "R0")
           (match_operand:SF 1 "register_operand" "R1")))
    (clobber (reg:SI r2))
    (clobber (reg:SI r3))]
   ""
   "call __compareSF"
   [(set_attr "type" "call")])

Where the R0 and R1 constraints resolve to the input registers for the 
routine.  Depending on your ISA and ABI, you may not even need to split 
this pattern post-reload.


r~

Re: Supporting FP cmp lib routines

[Mohamed Shafi]

2009/9/14 Richard Henderson <rth@redhat.com>:
> Another thing to look at, since you have hand-written routines and may be
> able to specify that e.g. only a subset of the normal call clobbered
> registers are actually modified, is to leave the call as a "compare" insn.
>  Something like
>
> (define_insn "*cmpsf"
>  [(set (reg:CC status-reg)
>        (compare:CC
>          (match_operand:SF 0 "register_operand" "R0")
>          (match_operand:SF 1 "register_operand" "R1")))
>   (clobber (reg:SI r2))
>   (clobber (reg:SI r3))]
>  ""
>  "call __compareSF"
>  [(set_attr "type" "call")])
>
> Where the R0 and R1 constraints resolve to the input registers for the
> routine.  Depending on your ISA and ABI, you may not even need to split this
> pattern post-reload.
>

I have implemented the above solution and it works. I have to support
the same for DF also. But with DF i have a problem with the
constraints. My target generates code for both big and little endian.
The ABI specifies that when a 64bit value is passed as an argument
they are passed in R6 and R7, R6 containing the most significant  long
word and R7 containing the least significant long word, regardless of
the  endianess mode. How can i do this in the DF compare pattern?

Regards,
Shafi

Re: Supporting FP cmp lib routines

[Joern Rennecke]

Quoting Mohamed Shafi <shafitvm@gmail.com>:
> I have implemented the above solution and it works. I have to support
> the same for DF also. But with DF i have a problem with the
> constraints. My target generates code for both big and little endian.
> The ABI specifies that when a 64bit value is passed as an argument
> they are passed in R6 and R7, R6 containing the most significant  long
> word and R7 containing the least significant long word, regardless of
> the  endianess mode. How can i do this in the DF compare pattern?

If 64 bit values are generally held in registers this way - or if it's OK
for the compiler to make it so - just change the nominal register numbers
in GCC so that endianness works as expected - register names and the nominal
numbers in gcc do not need to match.