From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96411 invoked by alias); 20 Apr 2016 20:29:17 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 96401 invoked by uid 89); 20 Apr 2016 20:29:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=team, HContent-Transfer-Encoding:8bit X-HELO: mail-yw0-f178.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kaFOfdtT7XbnDBBpxEpUGoQp5KrqqwoY4CFHuHmZNiA=; b=mpZDZ/dtdwRVzsFqM8JYYmF/phYjrtY7rTByRNnsUjbFa2D3CSWXzPeN8QJgn8cGTF ciP4x9ygHQM26PHKfFlGAE51QR4Q+6EBQdFvNOLuY3V2jwUe9MA0C9H4tKp38+2CDwF2 1BLb8BsGcF1VCt1o0qZvrlYJYCIiWaXzMNWZqcYcHhgiFLEIe+maHwEjd5q79Qchhdxf DaY3hQi0c2pHwToSWKqrqCdtl0lGZcjPjz9Epb7LWD0SZBVKjErIaV1XZ8vbKD8Ju1Q8 jkrRGRYcpl2fJgt+0XxrHZG0/ft0f0QEFVQnPJThaW3+zH6hkDfDpZmpIGa2E/lly0Bv iLoA== X-Gm-Message-State: AOPr4FXPCb8SyHqc9MYdtl3rVbb/xLkGoA4PKwEMJjXEsPuFx379M5MtlPhGd4NrNIKoQGrg X-Received: by 10.13.229.132 with SMTP id o126mr6717791ywe.254.1461184144230; Wed, 20 Apr 2016 13:29:04 -0700 (PDT) Subject: Re: question regarding div / std::div implementation References: <5717DF65.5060606@linaro.org> Cc: Daniel Gutson To: GNU C Library From: Adhemerval Zanella Message-ID: <5717E68D.2020905@linaro.org> Date: Wed, 20 Apr 2016 20:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-04/txt/msg00507.txt.bz2 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 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).