public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/103336] New: [arm64] operations on long double generate calls to libgcc
@ 2021-11-19 17:39 sebpop at gmail dot com
2021-11-19 18:04 ` [Bug rtl-optimization/103336] " pinskia at gcc dot gnu.org
2021-11-19 19:29 ` pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: sebpop at gmail dot com @ 2021-11-19 17:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
Bug ID: 103336
Summary: [arm64] operations on long double generate calls to
libgcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sebpop at gmail dot com
Target Milestone: ---
On testsuite/gcc.target/i386/long-double-64-1.c, gcc produces a call to
__multf3 on arm64 and the test checks that such a call is not generated on
x86_64.
$ cat a.c
long double
foo (long double x)
{
return x * x;
}
On arm64:
$ gcc -O2 -S -o- a.c
foo:
stp x29, x30, [sp, -16]!
mov v1.16b, v0.16b
mov x29, sp
bl __multf3
ldp x29, x30, [sp], 16
ret
On x64:
$ gcc -O2 -S -o- a.c
foo:
endbr64
fldt 8(%rsp)
fmul %st(0), %st
ret
Why GCC does not generate an fmul on arm64 instead of calling libgcc?
There is a related performance issue in libGeos:
https://github.com/libgeos/geos/issues/509
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/103336] [arm64] operations on long double generate calls to libgcc
2021-11-19 17:39 [Bug rtl-optimization/103336] New: [arm64] operations on long double generate calls to libgcc sebpop at gmail dot com
@ 2021-11-19 18:04 ` pinskia at gcc dot gnu.org
2021-11-19 19:29 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-19 18:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Arm64 does not have native higher than 644bit floating point. That is why it is
a libcall. X86_64's long double is 80bit fp too.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/103336] [arm64] operations on long double generate calls to libgcc
2021-11-19 17:39 [Bug rtl-optimization/103336] New: [arm64] operations on long double generate calls to libgcc sebpop at gmail dot com
2021-11-19 18:04 ` [Bug rtl-optimization/103336] " pinskia at gcc dot gnu.org
@ 2021-11-19 19:29 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-19 19:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If you want to have a consistency between platforms, it might be best if you
use _Float128 instead of long double but _Float128 is not supported on all
targets really. It is only supported on targets which have support for IEEE
128bit FP which includes x86_64, arm64 and PowerPC.
Again this is not really a bug or anything GCC can do better unless the newer
hardware comes out which has native support.
See https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html for more details on
this.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-11-19 19:29 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-19 17:39 [Bug rtl-optimization/103336] New: [arm64] operations on long double generate calls to libgcc sebpop at gmail dot com
2021-11-19 18:04 ` [Bug rtl-optimization/103336] " pinskia at gcc dot gnu.org
2021-11-19 19:29 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).