On 01/29/2016 12:37 AM, Richard Biener wrote:
To workaround this, I defined a new hook expand_divmod_libfunc, which
targets must override for expanding call to target-specific dimovd.
The "default" hook default_expand_divmod_libfunc() expands call to
libgcc2.c:__udivmoddi4() since that's the only "generic" divmod
available.
Is this a reasonable approach ?
Hum. How do they get to expand/generate it today? That said, I'm
no expert in this area.
A simpler solution may be to not do the transform if there is no
instruction for divmod.
Are we certain that the libcall is a win for any target?
I would have expected a default of
q = x / y
r = x - (q * y)
to be most efficient on modern machines. Even more so on targets like ARM that
have multiply-and-subtract instructions.
I suppose there's the case of the really tiny embedded chips that don't have
multiply patterns either. So that this default expansion still results in
multiple libcalls.
I do like the transformation, because for machines that don't have a divmod
instruction, being able to strength-reduce a mod operation to a multiply
operation is a nice win.
r~
