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