public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "svfuerst at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/47949] Missed optimization for -Os using xchg instead of mov.
Date: Wed, 02 Mar 2011 21:51:00 -0000	[thread overview]
Message-ID: <bug-47949-4-XRaaxodq7F@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47949-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47949

--- Comment #3 from Steven Fuerst <svfuerst at gmail dot com> 2011-03-02 21:51:12 UTC ---
Having a quick look at generated code... it appears that this pattern doesn't
come up all that often.  However, there is one case where it does: the epilogue
of a function. i.e. gcc tends to generate code looking like:

movl    %ebp, %eax
movq    8(%rsp), %rbx
movq    16(%rsp), %rbp
movq    24(%rsp), %r12
movq    32(%rsp), %r13
addq    $40, %rsp
ret

Replacing the move to %eax with an exchange with %ebp is a win in this
particular case.  The extra cycle or two of latency that xchg takes doesn't
matter as the other moves and ret instruction overlap in execution with it. 
Benchmarking on an opteron in 64bit mode confirms this hypothesis even in the
degenerate case where no other moves exist:

foo1:
    mov %edi, %eax
    retq

foo2:
    xchg %eax, %edi
    retq

foo1 and foo2 take the same time to execute.


  parent reply	other threads:[~2011-03-02 21:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-02  5:30 [Bug target/47949] New: " svfuerst at gmail dot com
2011-03-02 10:23 ` [Bug target/47949] " rguenth at gcc dot gnu.org
2011-03-02 10:53 ` jakub at gcc dot gnu.org
2011-03-02 21:51 ` svfuerst at gmail dot com [this message]
2021-06-08  9:52 ` pinskia at gcc dot gnu.org
2022-08-03  8:11 ` cvs-commit at gcc dot gnu.org
2022-08-04 18:23 ` 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-47949-4-XRaaxodq7F@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).