On Mon, 20 Feb 2023, Richard Biener via Gcc-patches wrote:
> On Sun, Feb 19, 2023 at 2:15 AM Maciej W. Rozycki <ma...@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
