Date: Tue, 30 Oct 2007 10:03:31 -1000 From: Juli Mallett <juli@clockworksquid.com> To: "Andrey A. Chernov" <ache@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/include _ctype.h Message-ID: <20071030200331.GA29309@toxic.magnesium.net> In-Reply-To: <200710272232.l9RMWSbK072082@repoman.freebsd.org> References: <200710272232.l9RMWSbK072082@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* "Andrey A. Chernov" <ache@FreeBSD.org> [ 2007-10-27 ] [ cvs commit: src/include _ctype.h ] > ache 2007-10-27 22:32:28 UTC > > FreeBSD src repository > > Modified files: > include _ctype.h > Log: > Micro-optimization of prev. commit, change > (_c < 0 || _c >= 128) to (_c & ~0x7F) Isn't that a non-optimization in code and a minor pessimization of readability? Maybe I'm getting rusty, but those seem to result in nearly identical code on i386 with a relatively modern GCC. Did you look at the compiler output for this optimization? Is there a specific expensive instruction you're trying to avoid? For such thoroughyl bit-aligned range checks, you shouldn't even get a branch for the former case. Is there a platform other than i386 I should look at where the previous expression is more clearly pessimized? Or a different compiler than GCC? juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071030200331.GA29309>