[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns

["mmitchel at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #59 from mmitchel at gcc dot gnu dot org  2008-12-11 00:14 -------
Steven, Zdenek --

Is there any way to teach the compiler to use the ARM __aeabi_divmod routine,
which provides both the quotient and remainder?  At least with -Os, that is
probably optimal.  In other words, once we get to:

prop0 = D.1286 % 45;
propsRes->pb = [plus_expr] (propsRes->pb + 1) + (int) (D.1286 / 45);

can we notice that we have both "D.1286 % 45" and "D.1286 / 45" and use the
divmod routine?

Furthermore, if we want to generate the loop instead, are the alternatives
you're considering sufficient to change code like:

  ... x / 45 ...

into the loop form?  In other words, rather than just considering this a
problem of transforming the hand-written loop into a division operation,
shouldn't we also be considering the problem of transforming division into the
loop form?

The style:

  a = x / N;
  b = x % N;

is pretty common; recognizing that pattern and generating a loop, or libcall to
__aeabi_divmod, seems like a good thing.  One could argue that __aeabi_divmod
itself should be responsible for noticing divisors that more profitably use
repeated subtraction than other methods, on CPUs that don't have a hardware
divide instruction.

Do we need a divmod optab?  Or, should we expect that if we provide an
appropriate pattern in the ARM back end, combine will be able to smush the
division and remainder operations together?

I guess where I'm going with this line of thinking is to argue that the
transformation to division is fine, and that we should treat that as canonical
-- but that we need a way to change divisions into repeated divisions if
appropriate.

-- Mark


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044