------- 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
