On Mon, May 30, 2016 at 12:45 AM, Richard Biener <rguent...@suse.de> wrote:
> Joseph - do you know sth about why there's not a full set of divmod
> libfuncs in libgcc?
Because udivmoddi4 isn't a libfunc, it is a helper function for the
div and mov libfuncs. Since we can compute the signed div and mod
results from udivmoddi4, there was no need to also add a signed
version of it. It was given a libfunc style name so that we had the
option of making it a libfunc in the future, but that never happened.
There was no support for calling any divmod libfunc until it was added
as a special case to call an ARM library (not libgcc) function. This
happened here
2004-08-09 Mark Mitchell <m...@codesourcery.com>
* config.gcc (arm*-*-eabi*): New target.
* defaults.h (TARGET_LIBGCC_FUNCS): New macro.
(TARGET_LIB_INT_CMP_BIASED): Likewise.
* expmed.c (expand_divmod): Try a two-valued divmod function as a
last resort.
...
* config/arm/arm.c (arm_init_libfuncs): New function.
(arm_compute_initial_eliminatino_offset): Return HOST_WIDE_INT.
(TARGET_INIT_LIBFUNCS): Define it.
...
Later, two ports added their own divmod libfuncs, but I don't see any
evidence that they were ever used, since there is no support for
calling divmod other than the expand_divmod last resort code that only
triggers for ARM.
It is only now that Prathamesh is adding gimple support for divmod
operations that we need to worry about getting this right, without
breaking the existing ARM library support or the existing udivmoddi4
support.
Jim
