From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 38DDD3858D32 for ; Sat, 18 Feb 2023 19:31:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 38DDD3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id EA12B92009C; Sat, 18 Feb 2023 20:31:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id DB50D92009B; Sat, 18 Feb 2023 19:31:30 +0000 (GMT) Date: Sat, 18 Feb 2023 19:31:30 +0000 (GMT) From: "Maciej W. Rozycki" To: Andrew Pinski cc: Palmer Dabbelt , gcc-patches@gcc.gnu.org Subject: Re: RISC-V: Add divmod instruction support In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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 Sat, 18 Feb 2023, Andrew Pinski via Gcc-patches wrote: > > > If we have division and remainder calculations with the same operands: > > > > > > a = b / c; > > > d = b % c; > > > > > > We can replace the calculation of remainder with multiplication + > > > subtraction, using the result from the previous division: > > > > > > a = b / c; > > > d = a * c; > > > d = b - d; > > > > > > Which will be faster. > > > > Do you have any benchmarks that show that performance increase? The ISA > > manual specifically says the suggested sequence is div+mod, and while > > those suggestions don't always pan out for real hardware it's likely > > that at least some implementations will end up with the ISA-suggested > > fusions. > > I suspect I will be needing this kind of patch for the core that I am > going to be using. > If anything this should be under a tuning option. Barring the fusion case, which indeed asks for a dedicated `divmod' pattern (and then I suppose a post-reload splitter or a peephole so that where one of the two results produced has eventually turned out unused, we have means to discard the unneeded machine instruction), isn't the generic transformation something for the middle end to do based on RTX costs? Maciej