Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
--- 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
_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
testedx, edx
cmovne eax, ecx
ret
_ctz(unsigned long long):
sub esp, 20
pushDWORD PTR [esp+28]
pushDWORD 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
_clz(unsigned long long):
mov edx, DWORD PTR [esp+4]
mov eax, DWORD PTR [esp+8]
testeax, 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
pushDWORD PTR [esp+28]
pushDWORD 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
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
https://gcc.gnu.org/bugs/
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
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
_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
testedx, edx
cmovne eax, ecx
ret
_ctz(unsigned long long):
sub esp, 20
pushDWORD PTR [esp+28]
pushDWORD 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
_clz(unsigned long long):
mov edx, DWORD PTR [esp+4]
mov eax, DWORD PTR [esp+8]
testeax, 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
pushDWORD PTR [esp+28]
pushDWORD 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. So
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
gcc -O0 -c -mabm -mbmi retard.c -o retard.o
^
|
|
|
int code(unsigned long long number) {
return (int) _tzcnt_u64(number);
}
objdump --disassemble-all retard.o
:
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 83 ec 10 sub$0x10,%rsp
8: 48 89 4d 10 mov%rcx,0x10(%rbp)
c: 48 8b 45 10 mov0x10(%rbp),%rax
10: 48 89 45 f8 mov%rax,-0x8(%rbp)
14: 31 c0 xor%eax,%eax
16: f3 48 0f bc 45 f8 tzcnt -0x8(%rbp),%rax
<-
1c: 48 83 c4 10 add$0x10,%rsp
20: 5d pop%rbp
Moron.
GNU Tools Cauldron 2023
We are pleased to invite you all to the next GNU Tools Cauldron, taking place in Cambridge, UK, on September 22-24, 2023. As for the previous instances, we have setup a wiki page for details: https://gcc.gnu.org/wiki/cauldron2023 Like last year, we are having to charge for attendance. We are still working out what we will need to charge, but it will be no more than £250. Attendance will remain free for community volunteers and others who do not have a commercial backer and we will be providing a small number of travel bursaries for students to attend. For all details of how to register, and how to submit a proposal for a track session, please see the wiki page. The Cauldron is organized by a group of volunteers. We are keen to add some more people so others can stand down. If you'd like to be part of that organizing committee, please email the same address. This announcement is being sent to the main mailing list of the following groups: GCC, GDB, binutils, CGEN, DejaGnu, newlib and glibc. Please feel free to share with other groups as appropriate. Richard (on behalf of the GNU Tools Cauldron organizing committee).
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On Mon, 5 Jun 2023 13:35:22 +0200 Gabriel Ravier via Gcc wrote: > [pages of bullshit deleted] > > 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. Sounds like the response of an idiot, or a malignant individual who isn't interested in improving their junk code. A not-uncommon response in today's world, full of arrogant, self-righteous, brittle individuals who just can't stand criticism. > PS: I hope you understand that I'm being somewhat generous when assuming > you genuinely want to get GCC's optimizer to improve, What? Are you claiming he *doesn't* want to see it improved? > Someone else might instead think you're just a troll Not you, of course. No sir. You're smarter than that, right? > that uses this as a pretext to send > inflammatory emails everywhere and waste the time of people like me. I thought the entire purpose of these threads was to call attention to the fact that our time IS being wasted already, by the shitty GCC optimizer? Dave
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On 6/6/23 00:23, Dave Blanchard wrote: On Mon, 5 Jun 2023 13:35:22 +0200 Gabriel Ravier via Gcc wrote: [pages of bullshit deleted] 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. Sounds like the response of an idiot, or a malignant individual who isn't interested in improving their junk code. A not-uncommon response in today's world, full of arrogant, self-righteous, brittle individuals who just can't stand criticism. Well, while I don't agree with your opinion on the reasonableness of that response (while I'd say it would perhaps be ever so slightly over the top as of right now, I don't think it'd be that unreasonable, and Stefan's current behavior could easily escalate to a point where one could very reasonably want to avoid even a smidge of indirect interaction with him), my point is that such a response is a plausible one, and given you appear to assume bad faith on the part of the GCC developers, I can only assume you agree with me that such a reaction is indeed plausible, if for a different reason. PS: I hope you understand that I'm being somewhat generous when assuming you genuinely want to get GCC's optimizer to improve, What? Are you claiming he *doesn't* want to see it improved? I don't think he doesn't care about optimizers. Certainly, looking at his website for just a few minutes makes it clear that he very much cares a lot about them. But his behavior is so puzzling as to make me question how it's possible to argue his case so badly, as to stretch my capacity to apply Hanlon's razor: indeed, a technically possible, if hopefully wrong conjecture, would be that he does care a lot about the optimizer, but simply hates GCC's optimizer so badly (for failing to optimize his code exactly how he wants it to be) that he doesn't even care about improving it and just wants to shout at the developers endlessly over it. This *should* be obviously stupid, but his current behavior on this list makes this possibility practically indistinguishable to me from one that assumes good faith (and seemingly cripplingly bad communication skills) and, as a result, I need to make a conscious effort to assume such good faith on his part. Someone else might instead think you're just a troll Not you, of course. No sir. You're smarter than that, right? Well, either I'm spending my time trying to get someone to stop completely destroying any potential for them to actually be able to contribute to GCC's development, or am I indeed quite the fool and completely wasting my time for the enjoyment of someone who doesn't care at all. That's all I'm trying to say, I don't think assuming good faith magically makes your IQ go up. that uses this as a pretext to send inflammatory emails everywhere and waste the time of people like me. I thought the entire purpose of these threads was to call attention to the fact that our time IS being wasted already, by the shitty GCC optimizer? Dave Wow, I'm actually impressed by how inflammatory you've managed to make this single sentence: it feels like you've managed to bottle up the very essence of flaming. Anyway, see above for what I meant by "waste the time of people like me", if you didn't understand what I meant by that.
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On Tue, 6 Jun 2023 01:59:42 +0200 Gabriel Ravier wrote: > [nothing of value] If this guy's threads are such a terrible waste of your time, how about employing your email client's filters to ignore his posts (and mine too) and fuck off? Now YOU'RE wasting everyone's time, as your type is so skilled at doing, refocusing an important discussion to generic whining about "muh feelings", instead of the real issue at hand here: GCC's optimizer is TERRIBLE! I for one appreciate this guy's posts, as this issue might have never been called to my attention otherwise; certainly not if this were relegated to the dusty corner of some bug list somewhere. I've now reverted to a much older version of GCC which will hopefully waste much fewer of my old computer's CPU cycles, while also (provably) not constantly breaking my system with all the added warnings and errors every release. Dave
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
> On Jun 5, 2023, at 8:09 PM, Dave Blanchard wrote: > > On Tue, 6 Jun 2023 01:59:42 +0200 > Gabriel Ravier wrote: > >> [nothing of value] > > If this guy's threads are such a terrible waste of your time, how about > employing your email client's filters to ignore his posts (and mine too) and > fuck off? Done. Since you have not shown any ability to have a civilized conversation, I will now use my email filter to be spared any further exposure. paul
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On 6/6/23 02:09, Dave Blanchard wrote: On Tue, 6 Jun 2023 01:59:42 +0200 Gabriel Ravier wrote: [nothing of value] If this guy's threads are such a terrible waste of your time, how about employing your email client's filters to ignore his posts (and mine too) and fuck off? Now YOU'RE wasting everyone's time, as your type is so skilled at doing, refocusing an important discussion to generic whining about "muh feelings", instead of the real issue at hand here: GCC's optimizer is TERRIBLE! Well, evidently you have a completely different understanding of what the "important discussion" here is. I've simply been trying to respond to your emails in a manner I thought appropriate: I didn't think you were sending mails with the expectation that it is apparently unacceptable for me to respond to them, especially when they contain multiple explicit direct questions. I for one appreciate this guy's posts, as this issue might have never been called to my attention otherwise; certainly not if this were relegated to the dusty corner of some bug list somewhere. I've now reverted to a much older version of GCC which will hopefully waste much fewer of my old computer's CPU cycles, while also (provably) not constantly breaking my system with all the added warnings and errors every release. I did not think Poe's law would become applicable to so many discussions on this mailing list, but here I am... I guess that leaves me with only one question: are you actually serious in your claim that this "much older version of GCC" will produce faster code than a recent one ? Dave
