Message ID | 20170725114502.5055-1-sebastian.huber@embedded-brains.de |
---|---|
State | New |
Headers | show |
> 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?
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.
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?
> 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.
> What is your opinion with respect to a -mno-fsmuld option or something > similar? Far better in my opinion (at least for LEON3).
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")])