From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932420AbbKDJCQ (ORCPT ); Wed, 4 Nov 2015 04:02:16 -0500 Received: from mail-lb0-f171.google.com ([209.85.217.171]:35390 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403AbbKDJCL (ORCPT ); Wed, 4 Nov 2015 04:02:11 -0500 From: Rasmus Villemoes To: James Bottomley Cc: Vitaly Kuznetsov , linux-scsi , "ulf.hansson\@linaro.org" , "andriy.shevchenko\@linux.intel.com" , "keescook\@chromium.org" , "linux-kernel\@vger.kernel.org" , "akpm\@linux-foundation.org" Subject: Re: [PATCH v2] string_helpers: fix precision loss for some inputs Organization: D03 References: <1446582810.6440.36.camel@HansenPartnership.com> <1446585708.6440.47.camel@HansenPartnership.com> <87d1vqd945.fsf@rasmusvillemoes.dk> <1446591259.6440.52.camel@HansenPartnership.com> <874mh2d5qh.fsf@rasmusvillemoes.dk> <1446594149.6440.70.camel@HansenPartnership.com> X-Hashcash: 1:20:151104:andriy.shevchenko@linux.intel.com::jVdBuuFU19s8Xipi:00000000000000000000000000000767 X-Hashcash: 1:20:151104:linux-scsi@vger.kernel.org::7QzPntBpqJPcTbpc:000000000000000000000000000000000000DM5 X-Hashcash: 1:20:151104:vkuznets@redhat.com::VOz7o4d3vBbRsWaP:0000000000000000000000000000000000000000001LXD X-Hashcash: 1:20:151104:ulf.hansson@linaro.org::7vfRyhAWtQmCcLav:0000000000000000000000000000000000000001oOZ X-Hashcash: 1:20:151104:akpm@linux-foundation.org::77Ma+LJ74N+mFv4F:0000000000000000000000000000000000002dFC X-Hashcash: 1:20:151104:linux-kernel@vger.kernel.org::Gl4YL10fJhS5R7ac:0000000000000000000000000000000002igN X-Hashcash: 1:20:151104:keescook@chromium.org::tJ35ZN6oSgt6fVfT:00000000000000000000000000000000000000004S/V X-Hashcash: 1:20:151104:james.bottomley@hansenpartnership.com::84OuPjPfy2BHavsR:0000000000000000000000004Hkd Date: Wed, 04 Nov 2015 10:02:07 +0100 In-Reply-To: <1446594149.6440.70.camel@HansenPartnership.com> (James Bottomley's message of "Tue, 03 Nov 2015 15:42:29 -0800") Message-ID: <87vb9icf3k.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 04 2015, James Bottomley wrote: > On Wed, 2015-11-04 at 00:26 +0100, Rasmus Villemoes wrote: >> On Tue, Nov 03 2015, James Bottomley wrote: >> >> Please spell it U32_MAX >> > >> > Why? there's no reason not to use the arithmetic UINT_MAX here. Either >> > works, of course but UINT_MAX is standard. >> >> We're dealing with explicitly sized integers > > An integer is explicitly sized: it's 32 bits. That's why UINT_MAX is > a universal constant. In the Linux universe, yes. It's kind of amusing how you try to argue based on the UINT_MAX name being (defined in a) standard while at the same time very much rely on sizeof(int) having a value which is not specified by the standard. I repeat: >> U32_MAX is the natural name for the appropriate constant. (and it's defined right next to UINT_MAX in kernel.h, so it's not like you'd have to introduce that macro). >> Also, you could do > U32_MAX instead of >= U32_MAX, but that's unlikely >> to make any difference (well, except it might generate slightly better >> code, since it would allow gcc to just test the upper half for being 0, >> which might be cheaper on some architectures than comparing to a >> literal). > > Heh if we're going to be that concerned about the code generation, then > we should just tell gcc exactly how to do it instead of hoping it can > work it out for itself, so > > while (blk_size >> 32) { > ... Nah, that would still require the compiler to be able to transform that to the other form, which apparently it isn't. On x86_64, the simplest is to load U32_MAX once into a register and then do r/r comparisons, but when it's possible to directly test the upper half (e.g. when the 64 bit value is represented in a pair of 32 bit registers) that's much simpler. gcc generates good code for 'blk_size > U32_MAX' on both x86_64 and x86_32, but ends up doing an extra cmp on x86_32 for >=, and ends up doing mov,shift,test inside the loop on x86_64 for 'blk_size >> 32'. Rasmus