From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36869) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcHxM-0003no-18 for qemu-devel@nongnu.org; Wed, 16 Sep 2015 15:01:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcHxI-0005v8-Rc for qemu-devel@nongnu.org; Wed, 16 Sep 2015 15:01:23 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:51091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcHxI-0005q8-M0 for qemu-devel@nongnu.org; Wed, 16 Sep 2015 15:01:20 -0400 References: <1442234754-15692-1-git-send-email-leon.alrae@imgtec.com> <1442234754-15692-3-git-send-email-leon.alrae@imgtec.com> <55F9B198.3070708@twiddle.net> From: Leon Alrae Message-ID: <55F9BC5D.6020604@imgtec.com> Date: Wed, 16 Sep 2015 20:00:45 +0100 MIME-Version: 1.0 In-Reply-To: <55F9B198.3070708@twiddle.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] target-mips: remove gen_mfc0_load64() and use tcg_gen_ld32s_tl() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: aurelien@aurel32.net On 16/09/15 19:14, Richard Henderson wrote: > On 09/14/2015 05:45 AM, Leon Alrae wrote: >> -static inline void gen_mfc0_load64 (TCGv arg, target_ulong off) >> -{ >> - tcg_gen_ld_tl(arg, cpu_env, off); >> - tcg_gen_ext32s_tl(arg, arg); >> -} >> - >> static inline void gen_mtc0_store32 (TCGv arg, target_ulong off) >> { >> TCGv_i32 t0 = tcg_temp_new_i32(); >> @@ -4972,17 +4966,19 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int reg, int sel) >> break; >> case 4: >> CP0_CHECK(ctx->insn_flags & ASE_MT); >> - gen_mfc0_load64(arg, offsetof(CPUMIPSState, CP0_YQMask)); >> + tcg_gen_ld32s_tl(arg, cpu_env, offsetof(CPUMIPSState, CP0_YQMask)); >> rn = "YQMask"; >> break; > > This change is broken for 64-bit guest and big-endian host -- one has to adjust > the offset in that case. I suspect that's why the extension was separate to > begin with... Uh, I think I wasn't expecting that ld32s_i64 actually does 32-bit load. It means that CP0_UserLocal needs fixing in current code. Thanks, Leon