public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "david at westcontrol dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/98884] Implement empty struct optimisations on ARM Date: Fri, 29 Jan 2021 12:30:15 +0000 [thread overview] Message-ID: <bug-98884-4-TcElBPaMuG@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98884-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98884 --- Comment #2 from David Brown <david at westcontrol dot com> --- Yes, ABI issues were my initial thought too. If so, then optimising away the assignments while leaving the stack manipulation (and possibly register allocations) in place would still be a significant improvement. However, I note that clang has no problem with generating ideal code here for the ARM - it is not bothered by the ABI. There could be several reasons for that. Perhaps the clang folk got the ABI wrong and the optimisation is not valid for the ARM EABI. Maybe the EABI used on the "arm (none)" target doesn't specify these details, meaning the optimisation is valid there even if it is not valid on "arm (linux)" targets. I don't know the details of the ABIs well enough to answer. If it is an ABI issue, then I'd be quite happy with an ARM-specific flag to enable an variation on the ABI that lets the compiler skip empty types entirely. When compiling for the Cortex-M devices, you rarely link much to pre-compiled code (other than the C library) and it's usually fine to break standards a bit to get more optimal code (like using "-ffast-math"). It would of course be best to have a general solution that works for all ARM users (and ideally other targets too) without needing a flag.
next prev parent reply other threads:[~2021-01-29 12:30 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-29 11:18 [Bug c++/98884] New: " david at westcontrol dot com 2021-01-29 11:43 ` [Bug target/98884] " redi at gcc dot gnu.org 2021-01-29 11:55 ` rguenth at gcc dot gnu.org 2021-01-29 12:30 ` david at westcontrol dot com [this message] 2021-01-29 12:35 ` jakub at gcc dot gnu.org 2021-01-29 12:48 ` jakub at gcc dot gnu.org 2021-02-01 15:18 ` david at westcontrol dot com 2021-02-01 15:46 ` david at westcontrol dot com 2021-02-01 16:34 ` jakub at gcc dot gnu.org
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-98884-4-TcElBPaMuG@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).