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 496E43858D1E for ; Mon, 9 Jan 2023 16:32:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 496E43858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nexgo.de Received: from mr5.vodafonemail.de ([145.253.228.165]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pEv4v-0004LQ-HK for gcc@gnu.org; Mon, 09 Jan 2023 11:32:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de; s=vfde-smtpout-mb-15sep; t=1673281968; bh=O6qENfQ46kDQj2DO/2L6FCnV+9STHVQojsGcgEes6GI=; h=Message-ID:From:To:References:In-Reply-To:Subject:Date: Content-Type:X-Mailer:From; b=aAkER764ec30iML6uzfAK0LwUVs3cuPB3RG3lUVmONouNarsMccrML2AW1bT8fK+m KK2efgHvuwzcolqlTGBOEAxtdgnCcG6YMDsueHEdVgo2EUWtPpsUdUU93yO/1Pp4Ag z6T2YSfFj8PmDMSP+z1FYpxCmzHg8rU1F8GBhawg= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr5.vodafonemail.de (Postfix) with ESMTPS id 4NrKHN6LX7z207P; Mon, 9 Jan 2023 16:32:48 +0000 (UTC) Received: from H270 (p5de6d091.dip0.t-ipconnect.de [93.230.208.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4NrKHD3fBmz9vFG; Mon, 9 Jan 2023 16:32:37 +0000 (UTC) Message-ID: <78300C8F5F0D4B7B96FB1EFB713C5575@H270> From: "Stefan Kanthak" To: "Paul Koning" Cc: References: <554A1354252F43BB8915A74129C41BE3@H270> <3BFE5710A2B04DA89EC334177EC28BC6@H270> <46F8B35E-93C9-4B76-90C1-217291D6509A@comcast.net> In-Reply-To: <46F8B35E-93C9-4B76-90C1-217291D6509A@comcast.net> Subject: Re: Widening multiplication, but no narrowing division [i386/AMD64] Date: Mon, 9 Jan 2023 17:27:12 +0100 Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-purgate-type: clean X-purgate: clean X-purgate-size: 2996 X-purgate-ID: 155817::1673281964-FBFFE4F8-6F965E2C/0/0 Received-SPF: pass client-ip=145.253.228.165; envelope-from=stefan.kanthak@nexgo.de; helo=mr5.vodafonemail.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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,RCVD_IN_DNSWL_LOW=-0.7,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_FAIL,SPF_HELO_PASS,TXREP 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: "Paul Koning" wrote: >> On Jan 9, 2023, at 10:20 AM, Stefan Kanthak wrote: >> >> "Paul Koning" wrote: >> >>>> On Jan 9, 2023, at 7:20 AM, Stefan Kanthak wrote: >>>> >>>> Hi, >>>> >>>> GCC (and other C compilers too) support the widening multiplication >>>> of i386/AMD64 processors, but DON'T support their narrowing division: >>> >>> I wonder if this changed in the recent past. >>> I have a pattern for this type of thing in pdp11.md: >> [...] >>> and I'm pretty sure this worked at some point in the past. >> >> Unfortunately the C standard defines that the smaller operand (of lesser >> conversion rank), here divisor, has to undergo a conversion to the "real >> common type", i.e. the broader operand (of higher conversion rank), here >> dividend. Unless the information about promotion/conversion is handed over >> to the code generator it can't apply such patterns -- as demonstrated by >> the demo code. > Yes, I was thinking the same. But I spent a while on that pattern -- I > wanted to support div/mod as a single operation because the machine has > that primitive. And I'm pretty sure I saw it work before I committed > that change. That's why I'm wondering if something changed. I can't tell from the past how GCC once worked, but today it can't (or doesn't) use such patterns, at least not on i386/AMD64 processors. To give another example where the necessary information is most obviously NOT propagated from front end to back end: --- clmul.c --- // widening carry-less multiplication unsigned long long clmul(unsigned long p, unsigned long q) { unsigned long long r = 0; unsigned long s = 1UL << 31; do { r <<= 1; if (q & s) #ifdef _MSC_VER (unsigned long) r ^= p; #else r ^= p; // no need to promote/convert p here! #endif } while (s >>= 1); return r; } --- EOF --- # https://gcc.godbolt.org/z/E99v7fEP3 clmul(unsigned long, unsigned long): push ebp mov ecx, -2147483648 xor eax, eax xor edx, edx push edi # OOPS: superfluous xor edi, edi # OOPS: superfluous push esi push ebx # OUCH: WTF? mov ebp, DWORD PTR [esp+24] mov ebx, 32 # OUCH: WTF? mov esi, DWORD PTR [esp+20] .L3: shld edx, eax, 1 add eax, eax test ebp, ecx je .L2 xor eax, esi xor edx, edi # OOPS: superfluous .L2: shr ecx, 1 sub ebx, 1 # OUCH: WTF? jne .L3 pop ebx # OUCH: WTF? pop esi pop edi # OOPS: superfluous pop ebp ret 8 superfluous instructions out of the total 25 instructions! NOT AMUSED Stefan