From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqRaN-0001WI-ND for qemu-devel@nongnu.org; Tue, 10 Dec 2013 12:59:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqRaD-00026M-14 for qemu-devel@nongnu.org; Tue, 10 Dec 2013 12:59:07 -0500 Message-ID: <52A7565B.50704@gmail.com> Date: Tue, 10 Dec 2013 11:58:51 -0600 From: Tom Musta MIME-Version: 1.0 References: <1386604035-2507-1-git-send-email-tommusta@gmail.com> <1386604035-2507-6-git-send-email-tommusta@gmail.com> <52A65FAA.1070403@twiddle.net> In-Reply-To: <52A65FAA.1070403@twiddle.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/18] target-ppc: Add ISA 2.06 divwe[u][o] Instructions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: qemu-ppc@nongnu.org On 12/9/2013 6:26 PM, Richard Henderson wrote: >> + tcg_gen_shli_i64(ra, cpu_gpr[rA(ctx->opcode)], 32); \ >> + /* check for MIN div -1 */ \ >> + int l3 = gen_new_label(); \ >> + tcg_gen_brcondi_i64(TCG_COND_NE, rb, -1l, l3); \ >> + tcg_gen_brcondi_i64(TCG_COND_EQ, ra, INT64_MIN, lbl_ov); \ > > The second test can never be true, since ra has 32 zero bits. > Thus the first test is also pointless. Hmm. Consider the case where GPR[RA] = 0xUUUUUUUU_80000000 (U=don't care) and GPR[RB] = 0xUUUUUUUU_FFFFFFFF. Without these checks, I do not believe overflow will be properly detected. > >> + gen_set_label(lbl_ov); /* overflow handling */ \ >> + \ >> + if (signed) { \ >> + tcg_gen_sari_i64(cpu_gpr[rD(ctx->opcode)], ra, 63); \ >> + } else { \ >> + tcg_gen_movi_i64(cpu_gpr[rD(ctx->opcode)], 0); \ >> + } \ > > Divide by zero from the signed case reads an uninitialized ra here. While it's > true that the result is undefined, I don't think we want to expose > uninitialized reads to the TCG optimizer. > > Although... what is that sari for anyway? The result is undefined in the > non-div-by-zero overflow case as well. We might as well use 0, or even > 0xdeadbeef, all the time, no? I don't disagree with the comment. I was being consistent with existing code for divw/divd. I suspect whomever wrote this was trying to match the hardware's implementation. But 0 is certainly a perfectly good undefined value and would simplify the code.