On 3 November 2016 at 18:36, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Thu, Nov 3, 2016 at 1:58 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>>> libfunc, as in "__{,u}divmod{di,ti}4 library function" is already
>>> implemented in libgcc. But the enablement of this function inside the
>>> compiler has to be performed by each target.
>>
>> So can we do it generically instead of duplicating it ~50 times?
>
> I guess it can be done. Currently the expander goes:
>
> --cut here--
> /* Check if optab_handler exists for divmod_optab for given mode. */
> if (optab_handler (tab, mode) != CODE_FOR_nothing)
> {
> quotient = gen_reg_rtx (mode);
> remainder = gen_reg_rtx (mode);
> expand_twoval_binop (tab, op0, op1, quotient, remainder, unsignedp);
> }
>
> /* Generate call to divmod libfunc if it exists. */
> else if ((libfunc = optab_libfunc (tab, mode)) != NULL_RTX)
> targetm.expand_divmod_libfunc (libfunc, mode, op0, op1,
> "ient, &remainder);
>
> else
> gcc_unreachable ();
> --cut here--
>
> so, by declaring divmod libfunc, the target also has to provide target hook.
>
> Let's ask authors of the original divmod patch for the details.
Yes, in the initial patch, the default version of the hook targeted
generic divmod functions in libgcc,
however since full set of divmod libfuncs wasn't available
(__divmoddi4 for instance),
we had to drop that.
I have couple of concerns:
a) I am not sure if __udivmoddi4() is generically available for all targets.
For aarch64, I can confirm that __udivmoddi4() isn't available (it has
hardware div, so the divmod transform
should never generate call to __udivmoddi4() on aarch64).
Please see: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01239.html
Can we safely assume that a target would have generic divmod libfunc
like __udivmoddi4
available if it doesn't support hardware div insn and doesn't define
target-specific divmod libfuncs ?
b) Targets like AVR, have their own divmod patterns in the backend for
doing the divmod transform
(and haven't registered target-specific divmod libfuncs via
set_optab_libfunc() ).
We would end up generating call to generic divmod libfuncs for these
targets even though
they have target-specific divmod libfuncs available. I wonder if these
targets should now use the
generic divmod transform instead ?
Thanks,
Prathamesh
>
> Uros.
