public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/108279] New: Improved speed for float128 routines Date: Tue, 03 Jan 2023 20:55:32 +0000 [thread overview] Message-ID: <bug-108279-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279 Bug ID: 108279 Summary: Improved speed for float128 routines Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Our soft-float routines, which are used for the basic float128 arithmetic (__addtf3, __subtf3, etc) are much slower than they need to be. Michael S has some routines which are considerably faster, at https://github.com/already5chosen/extfloat, which he would like to contribute to gcc. There is a rather lengthy thread in comp.arch starting with https://groups.google.com/g/comp.arch/c/Izheu-k00Nw . Current status of the discussion: The routines currently do not support rounding modes, they support round to nearest with tie even only. Adding such support would be feasible. Handling the rounding mode it is currently done in libgcc, by querying the hardware, leading to a high overhead for each call. This would not be needed if -ffast-math (or a relevant suboption) is specified. It would also be suitable as is (with a different name) for Fortran intrinsics such as matmul. Fortran is a bit special because rounding modes are default on procedure entry and are restored on procedure exit (which is why setting rounding modes in a subroutine is a no-op). This would allow to keep a local variable keeping track of the rounding mode. The current idea would be something like this: The current behavior of __addtf3 and friends could remain as is, but its speed could be improved,. but it would still query the hardware. There can be two additional routines for each arithmetic operation. One of them would implement the operation given a specified rounding mode (to be called from Fortran when the correct IEEE module is in use). The other one would just implement round-to-nearest, for use from Fortran intrinsics and from all other languages if the right flags are given. It would be good to bolt this onto some flag which is used for libgfortran, to make it accessible from C. Probably gcc14 material.
next reply other threads:[~2023-01-03 20:55 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-03 20:55 tkoenig at gcc dot gnu.org [this message] 2023-01-03 21:02 ` [Bug libgcc/108279] " tkoenig at gcc dot gnu.org 2023-01-04 10:43 ` jakub at gcc dot gnu.org 2023-01-04 17:14 ` tkoenig at gcc dot gnu.org 2023-01-04 22:19 ` already5chosen at yahoo dot com 2023-01-11 23:06 ` already5chosen at yahoo dot com 2023-01-12 23:24 ` tkoenig at gcc dot gnu.org 2023-01-13 0:34 ` already5chosen at yahoo dot com 2023-01-13 1:29 ` already5chosen at yahoo dot com 2023-01-14 9:21 ` tkoenig at gcc dot gnu.org 2023-01-14 10:22 ` tkoenig at gcc dot gnu.org 2023-01-14 23:52 ` already5chosen at yahoo dot com 2023-01-15 0:20 ` already5chosen at yahoo dot com 2023-01-15 15:13 ` tkoenig at gcc dot gnu.org 2023-01-15 19:17 ` tkoenig at gcc dot gnu.org 2023-01-15 19:28 ` jakub at gcc dot gnu.org 2023-01-15 22:27 ` already5chosen at yahoo dot com 2023-01-16 22:16 ` joseph at codesourcery dot com 2023-01-18 19:02 ` wilco at gcc dot gnu.org 2023-01-18 19:20 ` jakub at gcc dot gnu.org 2023-01-18 19:26 ` jakub at gcc dot gnu.org 2023-01-18 20:10 ` wilco at gcc dot gnu.org 2023-01-18 22:28 ` already5chosen at yahoo dot com 2023-01-18 23:31 ` already5chosen at yahoo dot com 2023-02-10 13:38 ` already5chosen at yahoo dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108279-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).