Re: question regarding div / std::div implementation

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 20-04-2016 17:07, Daniel Gutson wrote:
> On Wed, Apr 20, 2016 at 4:58 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>>
>> On 20-04-2016 16:44, Daniel Gutson wrote:
>>> Hi,
>>>
>>>    is there any reason that std::div / cstdlib div is not implemented
>>> in such a way that it is expanded to
>>> the assembly instruction -when available- that calculates both the
>>> remainder and the quotient,
>>> e.g. x86' div ?
>>>
>>> For example, why not an inline function with inline assembly? Or,
>>> should this require a gcc built-in?
>>
>> I believe because nobody really implemented this optimization and
>> my felling is if this is being a hotspot in your application you
>> will probably get more gains trying to rewrite it than using the
>> libc call.
> 
> then it won't be portable, or optimally-portable, meaning that the optimization
> would show up whenever my target supports it. Suppose I need to provide
> my application for several architectures, I would expect that I should
> be able to
> write my application using standard functions, and that it will get
> optimized for each platform.
> 
> I'm reporting it in bugzilla and asking to assign it to one of my team members.

I do not really get what exactly you are referring as non-portable,
since glibc div code is implemented as stdlib/div.c and these will
generate idivl instruction on x86_64 for all supported chips. And
afaik these are true for all supported architectures (I am not
aware of any architecture that added a more optimized
division/modulus operation with a *different* opcode).
 
I mean to use the integer operation directly instead of using the
libcall. The code is quite simple:

div_t
div (int numer, int denom)
{
  div_t result;

  result.quot = numer / denom;
  result.rem = numer % denom;

  return result;
}

You can try to add an inline version on headers, as such the one
for string.h, but I would strongly recommend you to either work on
your application if these are the hotspot (either by calling the
operations directly instead) or on compiler side to make it
handling it as builtin (and thus avoid the libcall).