public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/101200] Unneeded AND after shift Date: Fri, 25 Jun 2021 09:34:36 +0000 [thread overview] Message-ID: <bug-101200-4-5vfaUVbsHH@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-101200-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org, | |law at gcc dot gnu.org --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Doing everything in DImode or SImode has some advantages, but lots of disadvantages too. x86 can do 8/16/32/64bit arithmetics just fine (although 16bit can cause some performance problems). The second & 15 from the source is optimized away during GIMPLE operations. But later on reappears from just a zero extension from 8 bits to 64 bits, with a few bits known to be zero (so not & 255 but just & 15). I think the right pass to optimize this back is REE. If I manually undo the optimization that combine did and replace (insn 14 13 15 2 (parallel [ (set (reg:DI 95 [ a ]) (and:DI (subreg:DI (reg:QI 93 [ a ]) 0) (const_int 15 [0xf]))) (clobber (reg:CC 17 flags)) ]) "pr101200.c":9:10 494 {*anddi_1} with (insn 14 13 15 2 (set (reg:DI 95 [ a ]) (zero_extend:DI (reg:QI 93 [ a ]))) "pr101200.c":9:10 137 {zero_extendqidi2} then REE tries something but gives up anyway: Trying to eliminate extension: (insn 14 13 15 2 (set (reg:DI 0 ax [orig:95 a ] [95]) (zero_extend:DI (reg:QI 0 ax [orig:93 a ] [93]))) "pr101200.c":9:10 137 {zero_extendqidi2} (nil)) Tentatively merged extension with definition : (insn 12 10 13 2 (parallel [ (set (reg:DI 0 ax) (zero_extend:DI (lshiftrt:QI (reg:QI 0 ax [orig:82 d.0_1 ] [82]) (const_int 4 [0x4])))) (clobber (reg:CC 17 flags)) ]) "pr101200.c":8:17 -1 (nil)) Merge cancelled, non-mergeable definitions: (insn 12 10 13 2 (parallel [ (set (reg:QI 0 ax [orig:93 a ] [93]) (lshiftrt:QI (reg:QI 0 ax [orig:82 d.0_1 ] [82]) (const_int 4 [0x4]))) (clobber (reg:CC 17 flags)) ]) "pr101200.c":8:17 717 {*lshrqi3_1} (nil)) Elimination opportunities = 1 realized = 0 So, to handle this, REE would need to figure out that some ANDs following logical right shifts can be treated as zero extensions too and also be taught to handle lshiftrts, replace the QImode MEM read with zero extending one, widening the right shift from QImode to DImode too (or ideally to SImode given the behavior of x86) and optimizing away the zero extension (emitted as AND 15).
next prev parent reply other threads:[~2021-06-25 9:34 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-24 20:19 [Bug tree-optimization/101200] New: " steinar+gcc at gunderson dot no 2021-06-24 20:37 ` [Bug rtl-optimization/101200] " pinskia at gcc dot gnu.org 2021-06-24 20:45 ` pinskia at gcc dot gnu.org 2021-06-24 20:50 ` pinskia at gcc dot gnu.org 2021-06-25 9:34 ` jakub at gcc dot gnu.org [this message] 2021-06-25 9:38 ` [Bug target/101200] " jakub at gcc dot gnu.org 2021-06-25 10:38 ` steinar+gcc at gunderson dot no 2021-06-29 17:40 ` law 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-101200-4-5vfaUVbsHH@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).