diff mbox

[SPARC] Disable muldf3_extend for LEON/LEON3

Message ID 20170725114502.5055-1-sebastian.huber@embedded-brains.de
State New
Headers show

Commit Message

Sebastian Huber July 25, 2017, 11:45 a.m. UTC 
Prominent LEON2 chips like the AT697E and AT697F do not properly support
the FSMULD instruction.  LEON3 targets using the GRFPU-lite floating
point unit do not support the FSMULD in hardware.  Disable this
instruction for for all LEON/LEON3 targets for simplicity.

This leads to a code size increase and performance degradation on
GR712RC and GR740 targets.  The code generation for the fmaf() function
of Newlib changes for example from

00000000 <fmaf>:
   0:   9c 03 bf b0     add  %sp, -80, %sp
   4:   d2 23 a0 4c     st  %o1, [ %sp + 0x4c ]
   8:   d1 03 a0 4c     ld  [ %sp + 0x4c ], %f8
   c:   d0 23 a0 4c     st  %o0, [ %sp + 0x4c ]
  10:   d3 03 a0 4c     ld  [ %sp + 0x4c ], %f9
  14:   d4 23 a0 4c     st  %o2, [ %sp + 0x4c ]
  18:   81 a2 0d 29     fsmuld  %f8, %f9, %f0
  1c:   d1 03 a0 4c     ld  [ %sp + 0x4c ], %f8
  20:   91 a0 19 28     fstod  %f8, %f8
  24:   9c 03 a0 50     add  %sp, 0x50, %sp
  28:   81 a0 08 48     faddd  %f0, %f8, %f0
  2c:   81 c3 e0 08     retl
  30:   81 a0 18 c0     fdtos  %f0, %f0

to

00000000 <fmaf>:
   0:   9c 03 bf b0     add  %sp, -80, %sp
   4:   d0 23 a0 4c     st  %o0, [ %sp + 0x4c ]
   8:   d1 03 a0 4c     ld  [ %sp + 0x4c ], %f8
   c:   d2 23 a0 4c     st  %o1, [ %sp + 0x4c ]
  10:   81 a0 19 28     fstod  %f8, %f0
  14:   d1 03 a0 4c     ld  [ %sp + 0x4c ], %f8
  18:   95 a0 19 28     fstod  %f8, %f10
  1c:   d4 23 a0 4c     st  %o2, [ %sp + 0x4c ]
  20:   d1 03 a0 4c     ld  [ %sp + 0x4c ], %f8
  24:   81 a0 09 4a     fmuld  %f0, %f10, %f0
  28:   91 a0 19 28     fstod  %f8, %f8
  2c:   9c 03 a0 50     add  %sp, 0x50, %sp
  30:   81 a0 08 48     faddd  %f0, %f8, %f0
  34:   81 c3 e0 08     retl
  38:   81 a0 18 c0     fdtos  %f0, %f0

gcc/
	* config/sparc/sparc.md (muldf3_extend): Disable for LEON/LEON3
	targets.
---
 gcc/config/sparc/sparc.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Eric Botcazou July 25, 2017, 12:59 p.m. UTC | #1 
> Prominent LEON2 chips like the AT697E and AT697F do not properly support
> the FSMULD instruction.  LEON3 targets using the GRFPU-lite floating
> point unit do not support the FSMULD in hardware.  Disable this
> instruction for for all LEON/LEON3 targets for simplicity.

And penalize everyone else?
Sebastian Huber July 25, 2017, 12:59 p.m. UTC | #2 
On 25/07/17 14:59, Eric Botcazou wrote:

>> Prominent LEON2 chips like the AT697E and AT697F do not properly support
>> the FSMULD instruction.  LEON3 targets using the GRFPU-lite floating
>> point unit do not support the FSMULD in hardware.  Disable this
>> instruction for for all LEON/LEON3 targets for simplicity.
> And penalize everyone else?

Yes, everyone using LEON/LEON3 will no longer benefit from the FSMULD 
after this patch. This was discussed with Gaisler. We have to make a 
trade-off between correctness, performance and the number of GCC options.
Sebastian Huber July 25, 2017, 1:32 p.m. UTC | #3 
On 25/07/17 14:59, Sebastian Huber wrote:

> On 25/07/17 14:59, Eric Botcazou wrote:
>
>>> Prominent LEON2 chips like the AT697E and AT697F do not properly 
>>> support
>>> the FSMULD instruction.  LEON3 targets using the GRFPU-lite floating
>>> point unit do not support the FSMULD in hardware.  Disable this
>>> instruction for for all LEON/LEON3 targets for simplicity.
>> And penalize everyone else?
>
> Yes, everyone using LEON/LEON3 will no longer benefit from the FSMULD 
> after this patch. This was discussed with Gaisler. We have to make a 
> trade-off between correctness, performance and the number of GCC options.
>

What is your opinion with respect to a -mno-fsmuld option or something 
similar?
Eric Botcazou July 25, 2017, 1:40 p.m. UTC | #4 
> Yes, everyone using LEON/LEON3 will no longer benefit from the FSMULD
> after this patch. This was discussed with Gaisler. We have to make a
> trade-off between correctness, performance and the number of GCC options.

IMO we shouldn't introduce regressions like this, i.e. people should never be 
gratuitously penalized when they upgrade the compiler, this sends a very bad 
message.  The !TARGET_LEON part is probably OK but not the !TARGET_LEON3 part.
Eric Botcazou July 25, 2017, 1:42 p.m. UTC | #5 
> What is your opinion with respect to a -mno-fsmuld option or something
> similar?

Far better in my opinion (at least for LEON3).
diff mbox

Patch

diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
index b154003c54a..37b4b6e6884 100644
--- a/gcc/config/sparc/sparc.md
+++ b/gcc/config/sparc/sparc.md
@@ -6121,7 +6121,7 @@  visl")
   [(set (match_operand:DF 0 "register_operand" "=e")
 	(mult:DF (float_extend:DF (match_operand:SF 1 "register_operand" "f"))
 		 (float_extend:DF (match_operand:SF 2 "register_operand" "f"))))]
-  "(TARGET_V8 || TARGET_V9) && TARGET_FPU && !sparc_fix_ut699"
+  "(TARGET_V8 || TARGET_V9) && TARGET_FPU && !sparc_fix_ut699 && !TARGET_LEON && !TARGET_LEON3"
   "fsmuld\t%1, %2, %0"
   [(set_attr "type" "fpmul")
    (set_attr "fptype" "double")])