public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "amonakov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/111143] [missed optimization] unlikely code slows down diffutils x86-64 ASCII processing
Date: Sat, 26 Aug 2023 08:09:48 +0000	[thread overview]
Message-ID: <bug-111143-4-ibZjwbcWCa@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-111143-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #6 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Thanks.

i5-1335U has two "performance cores" (with HT, four logical CPUs) and eight
"efficiency cores". They have different micro-architecture. Are you binding the
benchmark to some core in particular?

On the "performance cores", 'add rbx, 1' can be eliminated ("executed" with
zero latency), this optimization appeared in the Alder Lake generation with the
"Golden Cove" uarch and was found by Andreas Abel. There are limitations (e.g.
it works for 64-bit additions but not 32-bit, the addend must be an immediate
less than 1024).

Of course, it is better to have 'add rbx, 1' instead of 'add rbx, rax' in this
loop on any CPU ('mov eax, 1' competes for ALU ports with other instructions,
so when it's delayed due to contention the dependent 'add rbx, rax; movsx rax,
[rbx]' get delayed too), but ascribing the difference to compiler scheduling on
a CPU that does out-of-order dynamic scheduling is strange.

  parent reply	other threads:[~2023-08-26  8:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24 20:05 [Bug rtl-optimization/111143] New: " eggert at cs dot ucla.edu
2023-08-24 20:05 ` [Bug rtl-optimization/111143] " eggert at cs dot ucla.edu
2023-08-24 20:06 ` eggert at cs dot ucla.edu
2023-08-24 20:14 ` pinskia at gcc dot gnu.org
2023-08-25  6:46 ` amonakov at gcc dot gnu.org
2023-08-26  3:33 ` eggert at cs dot ucla.edu
2023-08-26  8:09 ` amonakov at gcc dot gnu.org [this message]
2023-08-26 16:43 ` eggert at cs dot ucla.edu

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-111143-4-ibZjwbcWCa@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).