From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NVb8X-0000SI-9S
	for qemu-devel@nongnu.org; Thu, 14 Jan 2010 20:38:05 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NVb8R-0000PO-A1
	for qemu-devel@nongnu.org; Thu, 14 Jan 2010 20:38:03 -0500
Received: from [199.232.76.173] (port=44144 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NVb8R-0000PA-3B
	for qemu-devel@nongnu.org; Thu, 14 Jan 2010 20:37:59 -0500
Received: from mail2.shareable.org ([80.68.89.115]:38316)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1NVb8Q-0003em-NQ
	for qemu-devel@nongnu.org; Thu, 14 Jan 2010 20:37:58 -0500
Date: Fri, 15 Jan 2010 01:37:45 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 2/2] tcg-x86_64: Avoid unnecessary REX.B
	prefixes.
Message-ID: <20100115013745.GA30105@shareable.org>
References: <20100106010537.9C9D2CBB@are.twiddle.net>
	<20100114161003.GF16630@volta.aurel32.net>
	<4B4F5DEC.9090909@twiddle.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B4F5DEC.9090909@twiddle.net>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: laurent.desnogues@gmail.com, qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>

Richard Henderson wrote:
> On 01/14/2010 08:10 AM, Aurelien Jarno wrote:
> >With the above change, rex can be > 0xff. Not sure it's not a good idea
> >to not have an explicit cast when calling tcg_out8(), even if it
> >technically works.

> >What's the reason for removing the '&  0xff' part? tcg_out8() takes an 
> >uint8_t.
> 
> Yes, and the uint8_t truncates the value just fine.  Is there any 
> particular reason you want to clutter the code with a duplicate 
> truncation?  It might have been reasonable if the function name didn't 
> quite clearly indicate that a single byte was going to be output...

The & 0xff makes it clear that rex > 0xff is intentional; that you
have thought about it.

Otherwise it looks like rex > 0xff might be unintentional.  Anyone can
check the code isn't mistaken, but it's better if it doesn't *look*
like a mistake.  After all, there have been mistakes in this sort of
code elsewhere many times.

In this sense, I think it's not cluttering; it's removing excessive
subtlety.

I would hope that GCC optimises the & 0xff away.

-- Jamie