From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56227)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZGZVv-0006lf-KM
	for qemu-devel@nongnu.org; Sat, 18 Jul 2015 17:19:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZGZVu-0002is-Qn
	for qemu-devel@nongnu.org; Sat, 18 Jul 2015 17:19:19 -0400
Received: from hall.aurel32.net ([2001:bc8:30d7:100::1]:42619)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aurelien@aurel32.net>) id 1ZGZVu-0002i4-Lk
	for qemu-devel@nongnu.org; Sat, 18 Jul 2015 17:19:18 -0400
Date: Sat, 18 Jul 2015 23:19:17 +0200
From: Aurelien Jarno <aurelien@aurel32.net>
Message-ID: <20150718211917.GA12723@aurel32.net>
References: <1436958199-5181-1-git-send-email-aurelien@aurel32.net>
	<1436958199-5181-9-git-send-email-aurelien@aurel32.net>
	<55A8A2CB.70001@twiddle.net> <20150717103321.GA14985@aurel32.net>
	<55A9FF1A.9030704@twiddle.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55A9FF1A.9030704@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH RFC 8/9] tcg/optimize: do not simplify size
	changing moves
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-18 08:24, Richard Henderson wrote:
> On 07/17/2015 11:33 AM, Aurelien Jarno wrote:
> >For now I do wonder if we shouldn't get the size changing extu/exts
> >mandatory instead of reusing the 64-bit only version. This doesn't
> >change the generated code, at least on x86.
> 
> I'd be surprised if it did anywhere.  I don't mind starting with them being
> required, and then figuring out a way to optimize.

I have a patch series ready for that if you want I can post it as RFC.

That said looking more deeply into the problem you found I guess we can
solve that easily by using the same convention than the real CPU for
storing 32-bit constants in the TCG optimizer.

This roughly means the following code for the 32-bit ops:

         /* 32-bit ops generate 32-bit results.  */
         if (!(def->flags & TCG_OPF_64BIT)) {
             if (!TCG_TARGET_HAS_ext_i32_i64) {
                 /* registers are maintained sign-extended */
                 mask = (int32_t)mask;
                 affected = (int32_t)mask;
             } else if (!TCG_TARGET_HAS_extu_i32_i64) { 
                 /* registers are maintained zero-extended */
                 mask = (uint32_t)mask;
                 affected = (uint32_t)mask;
             } else {
                 /* high bits will be computed by ext/extu_i32_i64 */
                 mask = (uint32_t)mask;
                 affected = (uint32_t)mask;
             }
         }

And that would be fine for my patch series in preparation, as long as I
can predict the high part instead of considering it as garbage.

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