Date: Mon, 29 Oct 2007 21:48:16 +0100 From: Christoph Mallon <christoph.mallon@gmx.de> 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: <47264710.2000500@gmx.de> 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 wrote:
> 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)
>
> Revision Changes Path
> 1.33 +1 -1 src/include/_ctype.h
Actually this is rather a micro-pessimisation. Every compiler worth its
money transforms the range check into single unsigned comparison. The
latter test on the other hand on x86 gets probably transformed into a
test instruction. This instruction has no form with sign extended 8bit
immediate, but only with 32bit immediate. This results in a
significantly longer opcode (three bytes more) than a single
(unsigned)_c > 127, which a sane compiler produces. I suspect some RISC
machines need one more instruction for the "micro-optimised" code, too.
In theory GCC could transform the _c & ~0x7F back into a (unsigned)_c >
127, but it does not do this (the only compiler I found, which does this
transformation, is LLVM).
Further IMO it is hard to decipher what _c & ~0x7F is supposed to do.
Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47264710.2000500>