From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=keU5=6Q=ispras.ru=amonakov@sourceware.org>
Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84])
	by sourceware.org (Postfix) with ESMTPS id 53BB6385B51F
	for <gcc-patches@gcc.gnu.org>; Mon, 20 Feb 2023 13:33:00 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53BB6385B51F
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru
Received: from [10.10.3.121] (unknown [10.10.3.121])
	by mail.ispras.ru (Postfix) with ESMTPS id 402264076B47;
	Mon, 20 Feb 2023 13:32:56 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 402264076B47
Date: Mon, 20 Feb 2023 16:32:56 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: Richard Biener <richard.guenther@gmail.com>
cc: "Maciej W. Rozycki" <macro@orcam.me.uk>, Jeff Law <jeffreyalaw@gmail.com>, 
    Andrew Pinski <pinskia@gmail.com>, Palmer Dabbelt <palmer@dabbelt.com>, 
    gcc-patches@gcc.gnu.org
Subject: Re: RISC-V: Add divmod instruction support
In-Reply-To: <CAFiYyc2o0Gtu63ENpnULpovNevUm6Oxb3cCBDc+Ag=GOHhauhA@mail.gmail.com>
Message-ID: <72c83a06-6733-a982-04e8-64dbd754cb5e@ispras.ru>
References: <CALXbNshUoKPUqJiL2Nit7t4Hahg0wYMPMxcWRrwWZf8=7BADng@mail.gmail.com> <mhng-80df8fcb-f95d-4060-bbd1-a14cb4854250@palmer-ri-x1c9a> <CA+=Sn1m3TBcuPPLhy+EOyejAfKaK6SaD-8LeBqYdNCLzp_K2PA@mail.gmail.com> <alpine.DEB.2.21.2302181848430.25434@angie.orcam.me.uk>
 <26ca669c-70ce-e475-717e-3c36f1e1c703@gmail.com> <alpine.DEB.2.21.2302190110550.25434@angie.orcam.me.uk> <CAFiYyc2o0Gtu63ENpnULpovNevUm6Oxb3cCBDc+Ag=GOHhauhA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc-patches.gcc.gnu.org>


On Mon, 20 Feb 2023, Richard Biener via Gcc-patches wrote:

> On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> >
> > > The problem is you don't see it as a divmod in expand_divmod unless you expose
> > > a divmod optab.  See tree-ssa-mathopts.cc's divmod handling.
> >
> >  That's the kind of stuff I'd expect to happen at the tree level though,
> > before expand.
> 
> The GIMPLE pass forming divmod could indeed choose to emit the
> div + mul/sub sequence instead if an actual divmod pattern isn't available.
> It could even generate some fake mul/sub/mod RTXen to cost the two
> variants against each other but I seriously doubt any uarch that implements
> division/modulo has a slower mul/sub.

Making a correct decision requires knowing to which degree the divider is
pipelined, and costs won't properly reflect that. If the divider accepts
a new div/mod instruction every couple of cycles, it's faster to just issue
a div followed by a mod with the same operands.

Therefore I think in this case it's fair for GIMPLE level to just check if
the divmod pattern is available, and let the target do the fine tuning via
the divmod expander.

It would make sense for tree-ssa-mathopts to emit div + mul/sub when neither
'divmod' nor 'mod' patterns are available, because RTL expansion will do the
same, just later, and we'll rely on RTL CSE to clean up the redundant div.
But RISC-V has both 'div' and 'mod', so as I tried to explain in the first
paragraph we should let the target decide.

Alexander