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 20-04-2016 17:36, Daniel Gutson wrote:
> 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).

Off course it will generate a libcall, since stdlib.h header defines
it an external call and compiler does not have any information on
how to lower this.

>> 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 when building stdlib/div.c itself.

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

Because carrying such implementation adds header complexity and burden
maintainability, just check the string{2}.h header cleanup Wilco is

IMHO I do not see a compelling reason to add the usage of inline
assembly for such operation and I would avoid add a inline operation
just to remove the libcall. 

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