From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id DD4C83853D0C for ; Mon, 5 Jun 2023 11:35:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD4C83853D0C Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=gmail.com Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q68Ui-0000Uh-L0 for gcc@gnu.org; Mon, 05 Jun 2023 07:35:30 -0400 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-3f6ef9a928fso39088775e9.3 for ; Mon, 05 Jun 2023 04:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685964925; x=1688556925; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gobDZeJOaVtETdXCHMM8yjBrWkaneB2mkR9BPOJYNRo=; b=m0FlDNV4u1xbeaTI6oDNlrLuCO0IV5HOJQax6tgmYM4f+zIeZiEooJc0Xu8ESJRtcZ HwyJ/ZgMYTtri2GpQFBlALc2h821Q6tw8BNbap0FBRPS+04atliPkMd9eBozcLFXlJdo LhNThaUGEowpUkZi39VG7zc7vroHQc3BMqXW6r8XD7hDd3s20MM8qeUXj3jj4c2B6CxJ es3A7pmyV3frj/bCxLp7M6dR7Qi3TstLXasHY2+65KDwH2rauO1MrNT7t95yI6b9Az9H u87xu9TG93i1eknFNumpulctfK8xyyhHeDQAu+DaDUuFLKlAagDanv+Lqy1jZadmIDjm sOGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685964925; x=1688556925; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gobDZeJOaVtETdXCHMM8yjBrWkaneB2mkR9BPOJYNRo=; b=CGMj0t8b7sLIosY7kXaq8IV8L+Wp6TnhPv96O+qRvroOvoqWsWV/k3od3Brm14J/+p pbwEV20/BiZCbW/ETRplYHcY/M2gU0KfoXzqcOxdcljyZR9S/ZGC+8uvSa5iFgdSAmbG yTqySiRSDuPs3Nevhkjgnw2JTglztsDdL49LHdDBXyxowbhMywIqCC3jCiVPc2kI+uDe hm+A5xMh/qzLuqWw7ey5s6fLK1rn2viHe5FcmDRmvBxI9N8UoCNk2VezVP/MUZCC6kOw y7V1PWosZfSblOBTEUDZMU4zFp4ieuK/ho/obNYcaE/caEwcuQVW/t+duCqxBr543wjb EHIQ== X-Gm-Message-State: AC+VfDwnIKxemEGNxBomdOxXc1Vq4caEqQPpUTE2b5WQ0pMUJMAjQk/F Ql5Sy4Ue0pj33uO4O7Ra+yKQFPicQYtAUA== X-Google-Smtp-Source: ACHHUZ4qvsE2+LEC7BQM+aS41tHY+YwcI8ulD1M9FBYtX81dM9axT/wLC1GD5caDLN2HI5eXt91+ZQ== X-Received: by 2002:a05:600c:21a:b0:3f7:395a:c9fa with SMTP id 26-20020a05600c021a00b003f7395ac9famr1952884wmi.4.1685964924423; Mon, 05 Jun 2023 04:35:24 -0700 (PDT) Received: from [10.31.0.14] ([194.126.177.84]) by smtp.gmail.com with ESMTPSA id m11-20020a7bce0b000000b003f1958eeadcsm14027927wmc.17.2023.06.05.04.35.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jun 2023 04:35:23 -0700 (PDT) Message-ID: <5fe1271b-18f5-6faa-d48d-669c87bbd893@gmail.com> Date: Mon, 5 Jun 2023 13:35:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors? Content-Language: en-US To: Stefan Kanthak , gcc@gnu.org References: <5982A5DF4D694B4EA971B2597E833FC6@H270> From: Gabriel Ravier In-Reply-To: <5982A5DF4D694B4EA971B2597E833FC6@H270> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::32f; envelope-from=gabravier@gmail.com; helo=mail-wm1-x32f.google.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DKIM_VALID_EF=-0.1,FREEMAIL_FROM=0.001,NICE_REPLY_A=-0.09,RCVD_IN_DNSWL_NONE=-0.0001,SPF_HELO_NONE=0.001,SPF_PASS=-0.001,T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,NICE_REPLY_A,SPF_HELO_PASS,SPF_SOFTFAIL,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 > 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 > > > _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.