This is the mail archive of the mailing list for the glibc 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: question regarding div / std::div implementation

On Wed, Apr 20, 2016 at 5:29 PM, Adhemerval Zanella
<> wrote:
> On 20-04-2016 17:07, Daniel Gutson wrote:
>> On Wed, Apr 20, 2016 at 4:58 PM, Adhemerval Zanella
>> <> 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

I don't see it generating the idivl instruction, but
      callq  400430 <div@plt>
so I think it should be implemented as an inline function maybe with
inline assembly
(or rely on the pattern recognition as you suggest below).

> 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).

Could you please post an example and the gcc command line call where
you do get the idiv?

> 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).

Why should this be a builtin? I can implement it on gcc, but I still
don't see why should I pass the burden to the compiler
whereas it is a matter of library implementation.


Daniel F. Gutson
Engineering Manager

San Lorenzo 47, 3rd Floor, Office 5
CÃrdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:    dgutson

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