https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103344
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roger at nextmovesoftware dot
com
--- Comment #6 from Roger Sayle <roger at nextmovesoftware dot com> ---
mulshift's decision is based on the divisor and target CPU's timings (-mtune).
For example, -m32 uses mulshift for the udivmod divisor 1008, but not for 1000
(i.e. it's far more subtle than "doesn't work when divisor is larger than
100").
Unfortunately the (pruned-search) algorithm that GCC's expand uses makes it
impossible to print out the costs of different alternatives, instead all that
we know is that it was unable to find any instruction sequence that it
considered cheaper than calling __udivmoddi4. (and it may have considered
thousands of potential sequences, see PR87256).
