From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFHAE-0002WK-1q for qemu-devel@nongnu.org; Wed, 15 Jul 2015 03:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZFHAA-0006tQ-PC for qemu-devel@nongnu.org; Wed, 15 Jul 2015 03:31:34 -0400 Received: from mail-wg0-x231.google.com ([2a00:1450:400c:c00::231]:35052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZFHAA-0006t7-Ig for qemu-devel@nongnu.org; Wed, 15 Jul 2015 03:31:30 -0400 Received: by wgjx7 with SMTP id x7so25996105wgj.2 for ; Wed, 15 Jul 2015 00:31:29 -0700 (PDT) Sender: Paolo Bonzini References: <1436891912-14742-1-git-send-email-leon.alrae@imgtec.com> <20150714170928.GC7569@aurel32.net> <55A552F1.70000@redhat.com> <20150714183735.GA2685@aurel32.net> <55A57792.5070509@redhat.com> <20150714220938.GA11278@aurel32.net> From: Paolo Bonzini Message-ID: <55A60C4C.3070406@redhat.com> Date: Wed, 15 Jul 2015 09:31:24 +0200 MIME-Version: 1.0 In-Reply-To: <20150714220938.GA11278@aurel32.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] target-mips: apply workaround for TCG optimizations for MFC1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Leon Alrae , qemu-devel@nongnu.org, rth@twiddle.net On 15/07/2015 00:09, Aurelien Jarno wrote: >> > 2) 64-bit processors that have loads with 32-bit addresses. >> > >> > => qemu_ld/qemu_st can use 32-bit addresses to do the >> > truncation >> > >> > aarch64, I think, falls under this group > I don't think that works. We don't want to get a load with a 32-bit > address. We want a load of (guest_base + address), with guest_base > possibly being 64-bit, address being 32-bit and the result likely > being 64-bit. aarch64, IIUC, has complicated addressing modes with a 64-bit base and a 32-bit sign- or zero-extended index, which is exactly what you need here. However, the backend is not using it, so right now aarch64 is the same as x86. > Well the use of ADDR32 is a bit special, it only works because we can't > use %gs to add the guest base address. When we can't use %gs, ADDR32 > can't work. Yes. bsd-user would have to sign extend, in particular. > I don't think the register allocator is at fault at all. The register > tcg_reg_alloc_mov doesn't check for the register type because a TCG mov > is by definition only between registers of the same size. Ok, I see your point. If you put it like this :) the fault definitely lies in the backends. What I'm proposing would be in a new tcg_reg_alloc_trunc function, and it would require implementing a non-noop trunc. I still believe the register allocator can be improved to do 32-bit loads, though as an optimization and not as a bugfix: > > Even if the prefix was added, modifying the register allocator to use > > 32-bit loads would still be useful as an optimization, since on x86 > > 32-bit loads are smaller than 64-bit loads. > > AFAIK, that's already the case. The REXW prefix is only emitted for > 64-bit ops. Yes, but a load from a 64-bit register to a 32-bit destination emits REX.W. From Leon's dump: mov_i32 tmp1,w0.d0 => mov 0xe8(%r14),%rbp mov_i32 tmp0,tmp1 mov_i32 t8,tmp0 => mov %ebp,0x60(%r14) Note %rbp as the load destination and %ebp as the source of the store. Paolo