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 325EF3858CDA for ; Tue, 10 Jan 2023 16:49:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 325EF3858CDA Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=comcast.net Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=comcast.net Received: from resqmta-c1p-023463.sys.comcast.net ([2001:558:fd00:56::4]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pFHoK-0007f7-4y for gcc@gnu.org; Tue, 10 Jan 2023 11:49:17 -0500 Received: from resomta-c1p-023409.sys.comcast.net ([96.102.18.228]) by resqmta-c1p-023463.sys.comcast.net with ESMTP id FE6vp29RXw0SAFHoBprUfh; Tue, 10 Jan 2023 16:49:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1673369347; bh=Bp59RqvmH+n2c03ANqB721NQa1U02uxXJnxDz+7qo0c=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To:Xfinity-Spam-Result; b=Y5S5wFO8U9l0UjfVW/zWD0uHj4VsX8rYoemwvXyyEMr7FsDP/KNG9D9vHiMNjp5Cc iCfODeX7cXuCXPJWb6CnKg+GDvVjrG15P5aQkbBhhyV9nzasgvJsEcwDTXQTNeeVxX Tq+K8eu3ubnDq268P+hYkihkvHG8zMmtYFzZjwBlp3nRZGmWmBjCdrC6sslJNtSPyr xraYgDaLFYAbY9402PzzUvswxZ6cwdQiFN/g6gel1T1+9mxXThouteAnBbHWQ4MXk4 Cj/gEzz6DfjzmHYooI482qaDhRJ/x3JKj+cGg7rzoYwkjetbRTlYMsRyxn6dxQOooy Youvp5Y7XwVpg== Received: from smtpclient.apple ([73.60.223.101]) by resomta-c1p-023409.sys.comcast.net with ESMTPSA id FHo7pLgjLJHanFHo8pNGlh; Tue, 10 Jan 2023 16:49:07 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvhedrledvgddvlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhffrjgffvefgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpefgudeiudekudeufeeiffegvedtgfdtffelvedvgefhvdduhfduhfekieduleetfeenucfkphepjeefrdeitddrvddvfedruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehsmhhtphgtlhhivghnthdrrghpphhlvgdpihhnvghtpeejfedriedtrddvvdefrddutddupdhmrghilhhfrhhomhepphgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtpdhnsggprhgtphhtthhopedvpdhrtghpthhtohepshhtvghfrghnrdhkrghnthhhrghksehnvgigghhordguvgdprhgtphhtthhopehgtggtsehgnhhurdhorhhg X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Widening multiplication, but no narrowing division [i386/AMD64] From: Paul Koning X-Priority: 3 In-Reply-To: <78300C8F5F0D4B7B96FB1EFB713C5575@H270> Date: Tue, 10 Jan 2023 11:49:03 -0500 Cc: gcc@gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <3B78C086-D08C-4C09-AAE0-9B5B00C96FF3@comcast.net> References: <554A1354252F43BB8915A74129C41BE3@H270> <3BFE5710A2B04DA89EC334177EC28BC6@H270> <46F8B35E-93C9-4B76-90C1-217291D6509A@comcast.net> <78300C8F5F0D4B7B96FB1EFB713C5575@H270> To: Stefan Kanthak X-Mailer: Apple Mail (2.3696.120.41.1.1) Received-SPF: pass client-ip=2001:558:fd00:56::4; envelope-from=paulkoning@comcast.net; helo=resqmta-c1p-023463.sys.comcast.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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,SPF_HELO_PASS=-0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,SPF_HELO_PASS,SPF_SOFTFAIL,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: > On Jan 9, 2023, at 11:27 AM, Stefan Kanthak = wrote: >=20 > "Paul Koning" wrote: >=20 >>> ... >=20 >> 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. >=20 > 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. It turns out I was confused by the RTL generated by my pattern. That = pattern is for divmodhi, so it works as desired given same-size inputs. =20= I'm wondering if the case of longer dividend -- which is a common thing = for several machines -- could be handled by a define_peephole2 that = matches the sign-extend of the divisor followed by the (longer) divide. = I made a stab at that but what I wrote wasn't valid. So, question to the list: suppose I want to write RTL that matches what = Stefan is talking about, with a div or mod or divmod that has si results = and a di dividend (or hi results and an si dividend), how would you do = that? Can a define_peephole2 do it, and if so, what would it look like? paul