From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42756)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZG5ud-00038i-0a
	for qemu-devel@nongnu.org; Fri, 17 Jul 2015 09:42:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZG5ub-0002Bj-Q6
	for qemu-devel@nongnu.org; Fri, 17 Jul 2015 09:42:50 -0400
Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:34768)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZG5ub-0002BU-KV
	for qemu-devel@nongnu.org; Fri, 17 Jul 2015 09:42:49 -0400
Date: Fri, 17 Jul 2015 15:42:47 +0200
From: Aurelien Jarno <aurelien@aurel32.net>
Message-ID: <20150717134247.GA4343@aurel32.net>
References: <20150715205423.GA23115@aurel32.net> <55A82251.6020308@twiddle.net>
	<20150717102350.GA15281@aurel32.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150717102350.GA15281@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH v2 00/13] tcg/sparc v8plus code generation
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org

On 2015-07-17 12:23, Aurelien Jarno wrote:
> On 2015-07-16 22:29, Richard Henderson wrote:
> > On 07/15/2015 09:54 PM, Aurelien Jarno wrote:
> > >While I understand why we need the new trunc_shr_i32 opcode for MIPS64
> > >(the 32-bit values must be kept sign-extended), I currently fail to
> > >see why it is needed for SPARC.
> > 
> > As far as I recall, it improves code for extracting high parts of 64-bit
> > quantities.  Without this, we wind up with a 64-bit shift, requiring a
> > 64-bit temp register, followed by the "real" truncate which can copy the
> > data to a 32-bit destination register.
> 
> Ok, I understand the use case now. So it's not for correctness, but
> rather to generate more optimized code.

OTOH, it means that we always have to go through a 32-bit register first
when truncating a 64-bit value.

I mean we gain in the following case:
  shr_i64 t64, t64, i
  trunc_i64_i32 t32, t64
  ...

But we lose in the following case:
  trunc_i64_i32 t32, t64
  neg t32, t32
  ...

Overall I guess the advantages far outweigh the disadvantages.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net