On Fri, 3 Jun 2016, Jim Wilson wrote: > 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.
Ok, so as he is primarily targeting the special arm divmod libcall I suppose we can live with special-casing libcall handling to udivmoddi3. It would be nice to not lie about divmod availablilty as libcall though... - it looks like the libcall is also guarded on TARGET_HAS_NO_HW_DIVIDE (unless it was available historically like on x86). So not sure where to go from here. Richard.
