On 8 June 2016 at 19:53, Richard Biener wrote: > On Fri, 3 Jun 2016, Jim Wilson wrote: > >> On Mon, May 30, 2016 at 12:45 AM, Richard Biener 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 >> >> * 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. Hi, I have attached patch, which is rebased on trunk. Needed to update divmod-7.c, which now gets transformed to divmod thanks to your code-hoisting patch -;) We still have the issue of optab_libfunc() returning non-existent libcalls. As in previous patch, I am checking explicitly for "__udivmoddi4", with a FIXME note. I hope that's okay for now ? Bootstrapped and tested on x86_64-unknown-linux-gnu, armv8l-unknown-linux-gnueabihf. Bootstrap+test in progress on i686-linux-gnu. Cross-tested on arm*-*-*. Thanks, Prathamesh > > Richard.