Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753424AbYKKXyV (ORCPT ); Tue, 11 Nov 2008 18:54:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752103AbYKKXyK (ORCPT ); Tue, 11 Nov 2008 18:54:10 -0500 Received: from az33egw02.freescale.net ([192.88.158.103]:63306 "EHLO az33egw02.freescale.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751881AbYKKXyI (ORCPT ); Tue, 11 Nov 2008 18:54:08 -0500 Date: Tue, 11 Nov 2008 15:42:09 -0800 (PST) From: Trent Piepho X-X-Sender: xyzzy@t2.domain.actdsltmp To: Andrew Morton cc: djwong@us.ibm.com, Jean Delvare , linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org Subject: Re: [lm-sensors] [PATCH 1/2] Create a DIV_ROUND_CLOSEST macro to do division with rounding In-Reply-To: <20081111152007.ff508e26.akpm@linux-foundation.org> Message-ID: References: <20081111010132.1730.76566.stgit@elm3a70.beaverton.ibm.com> <20081111152007.ff508e26.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1505 Lines: 42 On Tue, 11 Nov 2008, Andrew Morton wrote: > On Tue, 11 Nov 2008 15:05:02 -0800 (PST) > Trent Piepho wrote: >> On Mon, 10 Nov 2008, Darrick J. Wong wrote: >>> #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f)) >>> #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d)) >>> #define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y)) >>> +#define DIV_ROUND_CLOSEST(x, divisor)( \ >>> +{ \ >>> + typeof(divisor) __divisor = divisor; \ >>> + (((x) + ((__divisor) / 2)) / (__divisor)); \ >>> +} \ >>> +) >> >> Maybe you can do away with the statement-expression extension? I've seen >> cases where it cases gcc to generate worse code. It seems like it >> shouldn't, but it does. I know DIV_ROUND_CLOSEST (maybe DIV_ROUND_NEAR?) >> uses divisor twice, but all the also divide macros do that too, so why does >> this one need to be different? > > The others need fixing too. Is it worth generating worse code for these simple macros? >> Note that if divisor is a signed variable, divisor/2 generates worse code >> than divisor>>1. > > yup. I wonder why the compiler doesn't do that for itself - is there a > case where it will generate a different result? main() { int x = -5; printf("%d %d\n", x>>1, x/2); } $ a.out -3 -2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/