public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/103611] GCC generates suboptimal code for SSE2/SSE4.1 64-bit integer element extraction on 32-bit x86 targets
Date: Mon, 13 Dec 2021 18:52:20 +0000	[thread overview]
Message-ID: <bug-103611-4-1wK8atOsJ7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103611-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103611

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:

https://gcc.gnu.org/g:149739c39475f3691e67aa0aee4f205f4e83392f

commit r12-5943-g149739c39475f3691e67aa0aee4f205f4e83392f
Author: Roger Sayle <roger@nextmovesoftware.com>
Date:   Mon Dec 13 18:48:22 2021 +0000

    x86: Avoid generating orb $0, %ah

    I'll post my proposed fix for PR target/103611 shortly, but this patch
    fixes another missed optimization opportunity revealed by that PR.
    Occasionally, reload materializes integer constants during register
    allocation sometimes resulting in unnecessary instructions such as:

    (insn 23 31 24 2 (parallel [
                (set (reg:SI 0 ax [99])
                    (ior:SI (reg:SI 0 ax [99])
                        (const_int 0 [0])))
                (clobber (reg:CC 17 flags))
            ]) "pr103611.c":18:73 550 {*iorsi_1}
         (nil))

    These then get "optimized" during the split2 pass, which realizes that
    no bits outside of 0xff00 are set, so this operation can be implemented
    by operating on just the highpart of a QIreg_operand, i.e. %ah, %bh, %ch
    etc., which leads to the useless "orb $0, %ah" seen in the reported PR.

    This fix catches the case of const0_rtx in relevant splitter, either
    eliminating the instruction or turning it into a simple move.

    2021-12-13  Roger Sayle  <roger@nextmovesoftware.com>

    gcc/ChangeLog
            * config/i386/i386.md (define_split any_or:SWI248 -> orb %?h):
            Optimize the case where the integer constant operand is zero.

    gcc/testsuite/ChangeLog
            * gcc.target/i386/pr103611-1.c: New test case.

  parent reply	other threads:[~2021-12-13 18:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08  0:55 [Bug target/103611] New: " john_platts at hotmail dot com
2021-12-08  1:04 ` [Bug target/103611] " john_platts at hotmail dot com
2021-12-08  1:10 ` john_platts at hotmail dot com
2021-12-08  1:28 ` pinskia at gcc dot gnu.org
2021-12-08  1:36 ` john_platts at hotmail dot com
2021-12-13 18:52 ` cvs-commit at gcc dot gnu.org [this message]
2021-12-18 13:53 ` cvs-commit at gcc dot gnu.org
2021-12-21 21:30 ` roger at nextmovesoftware 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-103611-4-1wK8atOsJ7@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: link
Be 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).