From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=XoCF=6P=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34])
	by sourceware.org (Postfix) with ESMTP id 6A46E3858D38
	for <gcc-patches@gcc.gnu.org>; Sun, 19 Feb 2023 01:14:28 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A46E3858D38
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 EAFB992009C; Sun, 19 Feb 2023 02:14:24 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id DBE8E92009B;
	Sun, 19 Feb 2023 01:14:24 +0000 (GMT)
Date: Sun, 19 Feb 2023 01:14:24 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jeff Law <jeffreyalaw@gmail.com>
cc: 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: <26ca669c-70ce-e475-717e-3c36f1e1c703@gmail.com>
Message-ID: <alpine.DEB.2.21.2302190110550.25434@angie.orcam.me.uk>
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>
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.0 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: <gcc-patches.gcc.gnu.org>

On Sat, 18 Feb 2023, Jeff Law wrote:

> >   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?
> I originally though the same way you did Maciej.
> 
> 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.

  Maciej