This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Sun, Jan 31, 2016 at 2:15 PM, Richard Henderson <rth@redhat.com> wrote:
> On 01/29/2016 12:37 AM, Richard Biener 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.
>>
>> A simpler solution may be to not do the transform if there is no
>> instruction for divmod.
>
>
> Are we certain that the libcall is a win for any target?
>
> I would have expected a default of
>
>         q = x / y
>         r = x - (q * y)
>
> to be most efficient on modern machines.  Even more so on targets like ARM
> that have multiply-and-subtract instructions.
>
> I suppose there's the case of the really tiny embedded chips that don't have
> multiply patterns either.  So that this default expansion still results in
> multiple libcalls.
>
> I do like the transformation, because for machines that don't have a divmod
> instruction, being able to strength-reduce a mod operation to a multiply
> operation is a nice win.
>
>
> r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]