Date: Thu, 01 Nov 2007 02:56:23 +0100 From: Christoph Mallon <christoph.mallon@gmx.de> To: Andrey Chernov <ache@nagual.pp.ru>, Bruce Evans <brde@optusnet.com.au>, Christoph Mallon <christoph.mallon@gmx.de>, src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/include _ctype.h Message-ID: <47293247.7060009@gmx.de> In-Reply-To: <20071031223911.GC90994@nagual.pp.ru> References: <200710272232.l9RMWSbK072082@repoman.freebsd.org> <47264710.2000500@gmx.de> <20071101024451.T4289@delplex.bde.org> <20071031223911.GC90994@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey Chernov wrote: > On Thu, Nov 01, 2007 at 03:23:56AM +1100, Bruce Evans wrote: >> In fact, one of the cleanups/optimizations in rev.1.5 and 1.6 by ache >> and me was to get rid of the mask. There was already a check for _c >> < 0, so the mask cost even more. The top limit was 256 instead of >> 128, so the point about 8bit immediates didn't apply, but I don't know >> of any machines where the mask is faster (didn't look hard :-). OTOH, >> _c is often a char or a u_char (it is declared as mumble_rune_t, but >> the functions are inline so the compiler can see the original type. >> If _c is u_char and u_char is uint8_t, then (_c < 0 || c >= 256) is >> always false, so the compiler should generate no code for it. The top >> limit of 256 was preferred so that this optimization is possible. A >> top limit of 128 doesn't work so well. > > Please see the tests posted in this thread. Please see my remarks on the tests. Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47293247.7060009>