From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63656 invoked by alias); 20 Apr 2016 21:16:05 -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 63622 invoked by uid 89); 20 Apr 2016 21:16:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=predictions, Skype, san, phone X-HELO: mail-oi0-f51.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=mymUttlxPh8nvotPurZbYBD+kaTPwgqvfZ5ZARbi5rA=; b=jqpqvwysJ/qHuK8li5Z83D139lyQ//L5UPUBxJvTj5qeus09bcSHX2ubwhQHmj5AwE 6cn5x20fuoOWsvVM4LCRBIb/sWNs8qQkQFCUnbyykyovyVn8eEzKHdkuJF9AbC3m5yLJ iGdILexnH4dwcwoozEIrlqtAcp9i0T4cdRL0t2PoFZwu3F8pGXkM/vs5ffbmdBleNbqH v4kjF+WqPVnqxBs1/HEWdDnqe7zaEuNCUZzHfoT75qrkvbbnhs76S32aApVjTb3xfuS5 3trPR9FwhB/qVers2n7nAmqpiQM/tkcv58MewVZPZtcTWY2YsdNdSRBkJY5MGojKpmc0 0Ztw== X-Gm-Message-State: AOPr4FWpAtqcrnfLP43ZWbfTRGj1PrMvNvYYxdhX0QQXv5aEsGdyNC9o+YuJE4fDzAji438X6hIXYaLa3V356RFE MIME-Version: 1.0 X-Received: by 10.202.196.72 with SMTP id u69mr4525044oif.116.1461186951033; Wed, 20 Apr 2016 14:15:51 -0700 (PDT) In-Reply-To: <5717EB44.5020508@linaro.org> References: <5717DF65.5060606@linaro.org> <5717E68D.2020905@linaro.org> <5717EB44.5020508@linaro.org> Date: Wed, 20 Apr 2016 21:16:00 -0000 Message-ID: Subject: Re: question regarding div / std::div implementation From: Daniel Gutson To: Adhemerval Zanella Cc: GNU C Library Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-04/txt/msg00513.txt.bz2 On Wed, Apr 20, 2016 at 5:49 PM, Adhemerval Zanella wrote: > > > 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 opt= imization >>>> 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. >> >> FWIW, https://sourceware.org/bugzilla/show_bug.cgi?id=3D19974 >> >>> >>> 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 >> 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 =3D numer / denom; >>> result.rem =3D 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 > pushing. > > 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. OK with no inline asm, but a libcall might be expensive specially in a tight loop and messes with predictions; a builtin is nonportable as well. --=20 Daniel F. Gutson Engineering Manager San Lorenzo 47, 3rd Floor, Office 5 C=C3=B3rdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson