Re: RISC-V: Add divmod instruction support

[Richard Biener <richard.guenther@gmail.com>]

On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> 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.

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.

Richard.

>
>   Maciej