public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nicholas Vinson <nvinson234@gmail.com>
To: gcc@gcc.gnu.org
Subject: Re: Who cares about performance (or Intel's CPU errata)?
Date: Sun, 28 May 2023 02:40:55 -0400	[thread overview]
Message-ID: <958cc2e2-62c4-498a-e408-600ffae56d11@gmail.com> (raw)
In-Reply-To: <8DB226CF451A4430A8D7D5CBFE6B3972@H270>


On 5/27/23 18:52, Stefan Kanthak wrote:
> "Andrew Pinski" <pinskia@gmail.com> wrote:
>
>> On Sat, May 27, 2023 at 2:25 PM Stefan Kanthak <stefan.kanthak@nexgo.de> wrote:
>>> Just to show how SLOPPY, INCONSEQUENTIAL and INCOMPETENT GCC's developers are:
>>>
>>> --- dontcare.c ---
>>> int ispowerof2(unsigned __int128 argument) {
>>>      return __builtin_popcountll(argument) + __builtin_popcountll(argument >> 64) == 1;
>>> }
>>> --- EOF ---
>>>
>>> GCC 13.3    gcc -march=haswell -O3
>>>
>>> https://gcc.godbolt.org/z/PPzYsPzMc
>>> ispowerof2(unsigned __int128):
>>>          popcnt  rdi, rdi
>>>          popcnt  rsi, rsi
>>>          add     esi, edi
>>>          xor     eax, eax
>>>          cmp     esi, 1
>>>          sete    al
>>>          ret
>>>
>>> OOPS: what about Intel's CPU errata regarding the false dependency on POPCNTs output?
>> Because the popcount is going to the same register, there is no false
>> dependency ....
>> The false dependency errata only applies if the result of the popcnt
>> is going to a different register, the processor thinks it depends on
>> the result in that register from a previous instruction but it does
>> not (which is why it is called a false dependency). In this case it
>> actually does depend on the previous result since the input is the
>> same as the input.
> OUCH, my fault; sorry for the confusion and the wrong accusation.
>
> Nevertheless GCC fails to optimise code properly:
>
> --- .c ---
> int ispowerof2(unsigned long long argument) {
>      return __builtin_popcountll(argument) == 1;
> }
> --- EOF ---
>
> GCC 13.3    gcc -m32 -mpopcnt -O3
>
> https://godbolt.org/z/fT7a7jP4e
> ispowerof2(unsigned long long):
>          xor     eax, eax
>          xor     edx, edx
>          popcnt  eax, [esp+4]
>          popcnt  edx, [esp+8]
>          add     eax, edx                 # eax is less than 64!
Less than or equal to 64 (consider the case when input is (unsigned long 
long)-1)
>          cmp     eax, 1    ->    dec eax  # 2 bytes shorter
>          sete    al
>          movzx   eax, al                  # superfluous
Not when dec is used. Use dec and omit this instruction, you may get a 
result value of 0xffffff00 (consider the case when input is (unsigned 
long long)0).
>          ret
>
> 5 bytes and 1 instruction saved; 5 bytes here and there accumulate to
> kilo- or even megabytes, and they can extend code to cross a cache line
> or a 16-byte alignment boundary.
>
> JFTR: same for "__builtin_popcount(argument) == 1;" and 32-bit argument
>
> JFTR: GCC is notorious for generating superfluous MOVZX instructions
>        where its optimiser SHOULD be able see that the value is already
>        less than 256!
>
> Stefan

      parent reply	other threads:[~2023-05-28  6:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-27 21:20 Stefan Kanthak
2023-05-27 21:47 ` Andrew Pinski
2023-05-27 22:52   ` Stefan Kanthak
2023-05-27 23:18     ` Mark Wielaard
2023-05-27 23:30     ` Andrew Pinski
2023-05-28  7:47       ` Stefan Kanthak
2023-05-28 12:29       ` David Brown
2023-05-29 18:11       ` Who cares about size? (was: Who cares about performance (or Intel's CPU errata)?) Stefan Kanthak
2023-05-28  6:40     ` Nicholas Vinson [this message]

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=958cc2e2-62c4-498a-e408-600ffae56d11@gmail.com \
    --to=nvinson234@gmail.com \
    --cc=gcc@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).