public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "peter at cordes dot ca" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/82940] Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc Date: Sun, 22 Aug 2021 22:16:32 +0000 [thread overview] Message-ID: <bug-82940-4-MBZdrkyZka@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-82940-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940 Peter Cordes <peter at cordes dot ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter at cordes dot ca --- Comment #6 from Peter Cordes <peter at cordes dot ca> --- For a simpler test case, GCC 4.8.5 did redundantly mask before using bitfield-insert, but GCC 9.2.1 doesn't. unsigned merge2(unsigned a, unsigned b){ return (a&0xFFFFFF00u) | (b&0xFFu); } https://godbolt.org/z/froExaPxe # PowerPC (32-bit) GCC 4.8.5 rlwinm 4,4,0,0xff # b &= 0xFF is totally redundant rlwimi 3,4,0,24,31 blr # power64 GCC 9.2.1 (ATI13.0) rlwimi 3,4,0,255 # bit-blend according to mask, rotate count=0 rldicl 3,3,0,32 # Is this zero-extension to 64-bit redundant? blr But ppc64 GCC does zero-extension of the result from 32 to 64-bit, which is probably not needed unless the calling convention has different requirements for return values than for incoming args. (I don't know PPC well enough.) So for at least some cases, modern GCC does ok. Also, when the blend isn't split at a byte boundary, even GCC4.8.5 manages to avoid redundant masking before the bitfield-insert. unsigned merge2(unsigned a, unsigned b){ return (a & 0xFFFFFF80u) | (b & 0x7Fu); } rlwimi 3,4,0,25,31 # GCC4.8.5, 32-bit so no zero-extension blr
next prev parent reply other threads:[~2021-08-22 22:16 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-82940-4@http.gcc.gnu.org/bugzilla/> 2021-08-01 7:16 ` pinskia at gcc dot gnu.org 2021-08-01 9:57 ` segher at gcc dot gnu.org 2021-08-22 22:16 ` peter at cordes dot ca [this message] 2021-08-23 15:40 ` segher at gcc dot gnu.org 2021-08-23 15:45 ` segher at gcc dot gnu.org 2023-04-11 17:05 ` aagarwa 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-82940-4-MBZdrkyZka@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).