Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Gabriel Ravier <gabravier@gmail.com>]

On 6/5/23 12:17, Stefan Kanthak wrote:
> --- failure.c ---
> int _clz(unsigned long long argument) {
>      return __builtin_clzll(argument);
> }
>
> int _ctz(unsigned long long argument) {
>      return __builtin_ctzll(argument);
> }
> --- EOF ---
>
> GCC 13.1    -m32 -mabm -mbmi -mlzcnt -O3 failure.c
>
> <https://godbolt.org/z/MMf11hKch>
> _clz(unsigned long long):
>          mov     edx, DWORD PTR [esp+8]
>          xor     ecx, ecx
>          xor     eax, eax
>          lzcnt   eax, DWORD PTR [esp+4]
>          add     eax, 32
>          lzcnt   ecx, edx
>          test    edx, edx
>          cmovne  eax, ecx
>          ret
> _ctz(unsigned long long):
>          sub     esp, 20
>          push    DWORD PTR [esp+28]
>          push    DWORD PTR [esp+28]
>          call    __ctzdi2
>          add     esp, 28
>          ret
>
> OUCH: although EXPLICITLY enabled via -mabm (for AMD processors) and -mbmi
>        (for Intel processors), GCC generates slowmotion code calling __ctzdi2()
>        instead of TZCNT instructions available since 10 (in words: TEN) years.
>
>
> GCC 13.1    -m32 -march=i386 -O3 failure.c
>
> <https://godbolt.org/z/16ezfaexb>
> _clz(unsigned long long):
>          mov     edx, DWORD PTR [esp+4]
>          mov     eax, DWORD PTR [esp+8]
>          test    eax, eax
>          je      .L2
>          bsr     eax, eax
>          xor     eax, 31
>          ret
> .L2:
>          bsr     eax, edx
>          xor     eax, 31
>          lea     eax, [eax+32]
>          ret
> _ctz(unsigned long long):
>          sub     esp, 20
>          push    DWORD PTR [esp+28]
>          push    DWORD PTR [esp+28]
>          call    __ctzdi2
>          add     esp, 28
>          ret
>
> OUCH²: the BSF/BSR instructions were introduced 38 (in words: THIRTY-EIGHT)
>         years ago with the i386 processor, but GCC fails to know/use BSF --
>         a real shame!
>
> OUCH³: an optimising compiler would of course generate "JMP __ctzdi2" instead
>         of code fiddling with the stack!
>
> Stefan Kanthak
>

Hi,

While the optimization concerns your email raises appear to be genuine 
to some degree, I must admit to being quite clueless as to why, exactly, 
after at least 2 years of intermittently sending various seemingly quite 
incensed emails to this list, you appears not to have, at any point, 
questioned whether this method of action is in any way effective.

I myself have, too, made a hobby of investigating the capabilities of 
GCC's optimizer on various pieces of code, and trying to get it 
improved, by filing various appropriately formulated bugs in GCC's 
bugzilla whenever it seemed appropriate to do so (see e.g. 
https://gcc.gnu.org/PR94795, https://gcc.gnu.org/PR98957, 
https://gcc.gnu.org/PR102224 or https://gcc.gnu.org/PR104371 for what I 
believe to be pretty good examples of how to file such a bug).

I have not spent all this time sending various inflammatory emails to 
mailing lists not made for that purpose, and I am quite puzzled by the 
fact you appear to have concluded that doing so is appropriate. Should 
the page on GCC's website about the mailing lists perhaps contain a 
mention that the main mailing list is not made for spamming complaints 
about minor bugs ? I'd have figured it'd be self-evident, but evidently 
it seems this might perhaps be necessary...

Anyway, this leaves me with two more things I'd like to ask you about:

1. Why exactly are you so mad at GCC's optimizer and constantly belittle 
its capacities ? Did a GCC developer working on the optimizer destroy 
your hometown and salt the earth or something ? I also don't get why you 
put "optimizer" between quotes like that - is this supposed to imply 
calling GCC's optimizer as such is some insult to some hypothetical 
better optimizer ? (note: I say hypothetical because I haven't seen any 
optimizer that would be so much better than GCC's as to make it seem 
insultingly bad compared to it - Clang is comparable to GCC in its 
capacities but you also appear to hate it, given what I've seen 
elsewhere, and I'd expect other compilers like ICC and MSVC to be the 
ones that would be the butt of the joke here, given how poor they are 
compared to GCC and Clang...)

2. Are you aware that these emails are not only pretty useless, but 
potentially actively counterproductive ? I'd personally expect GCC 
developers, who are rightfully not particularly happy at the thought of 
having to constantly suffer your belittling emails, to at best actively 
ignore them - but even worse from what I presume would be your POV (that 
of someone who wants GCC's optimizer to improve), this constant spam 
might give rise to what would be a pretty reasonable response: to be 
biased against any proposed improvement that comes from or derives from 
your emails. Arguably, to not be biased against them would encourage you 
to keep sending more emails, which people do not want as of now.


PS: I hope you understand that I'm being somewhat generous when assuming 
you genuinely want to get GCC's optimizer to improve, and are simply 
failing to work effectively towards this goal. Someone else might 
instead think you're just a troll that uses this as a pretext to send 
inflammatory emails everywhere and waste the time of people like me.