Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

[Richard Biener <rguenther at suse dot de>]

On Thu, 28 Jan 2016, Jim Wilson wrote:

> On Thu, Jan 28, 2016 at 5:37 AM, Richard Biener <rguenther@suse.de> 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.
> 
> Currently, the only place where a divmod libfunc can be called is in
> expand_divmod in expmed.c, which can return either the div or mod
> result, but not both.  If this is called for the mod result, and there
> is no div insn, and no mod insn, and no mod libfunc, then it will call
> the divmod libfunc to generate the mod result.  This is exactly the
> case where the ARM port needs it, as this code was written for the
> arm.
> 
> There are 3 targets that define a divmod libfunc: arm, c6x, and spu.
> The arm port is OK, because expand_divmod does the right thing for
> arm, using the arm divmod calling convention.  The c6x port is OK
> because it defines mod insns and libfuncs, and hence the divmod
> libfunc will never be called and is redundant.  The spu port is also
> OK, because it defines mod libcalls, and hence the divmod libfunc will
> never be called, and is likewise redundant.  Both the c6x and spu
> ports have their own divmod library functions in
> libgcc/config/$target.  The divmod library functions are called by the
> div and mod library functions, so they are necessary, they are just
> never directly called.  Both the c6x and spu port uses the current
> libgcc __udivmoddi4 calling convention with a pointer to the mod
> result, which is different and incompatible to the ARM convention of
> returning a double size result that contains div and mod.
> 
> WIth Prathamesh's patch to add support to the tree optimizers to
> create divmod operations, the c6x and spu ports break.  The divmod
> libfuncs are no longer redundant, and will be called, except with the
> wrong ABI, so we need to extend the divmod support to handle multiple
> ABIs.  This is why Prathamesh added the target hook for the divmod
> libcall, so the target can specify the ABI used by its divmod
> libcalls.  Prathamesh has correct support for ARM (current code), and
> apparently correct code for c6x and spu (libgcc udivmodsi4).

Thanks for the explanation.

I wonder if rather than introducing a target hook ports could use
a define_expand expanding to a libcall for this case?

That said, I've reviewed the GIMPLE parts of the patch and am
happy with that.  I'd prefer if somebody with more RTL-expansion
fu would review the rest of the patch.

> > A simpler solution may be to not do the transform if there is no
> > instruction for divmod.
> 
> This prevents the optimization from happening on ARM, which has divmod
> libfuncs but no divmod insn.  We want the optimization to happen
> there, as if we need both div and mod results, then calling the divmod
> libfunc is faster than calling both the div and mod libfuncs.

Ok, understood.  It also affects all > word mode ops on all targets
I think (not sure if we have TImode divmod in libgcc...).

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)