From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XRNtf-0000Sc-JJ for qemu-devel@nongnu.org; Tue, 09 Sep 2014 12:04:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XRNtW-0006EX-Ib for qemu-devel@nongnu.org; Tue, 09 Sep 2014 12:03:59 -0400 Sender: Richard Henderson Message-ID: <540F24DF.9080805@twiddle.net> Date: Tue, 09 Sep 2014 09:03:43 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1409246113-6519-1-git-send-email-pbonzini@redhat.com> <1409246113-6519-16-git-send-email-pbonzini@redhat.com> <5408AEF7.7030000@gmail.com> In-Reply-To: <5408AEF7.7030000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 15/17] ppc: store CR registers in 32 1-bit registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tom Musta , Paolo Bonzini , qemu-devel@nongnu.org Cc: dgibson@redhat.com, qemu-ppc@nongnu.org On 09/04/2014 11:27 AM, Tom Musta wrote: >> - tcg_gen_trunc_tl_i32(cpu_crf[crf], cpu_so); >> + tcg_gen_trunc_tl_i32(cpu_cr[crf * 4 + CRF_SO], cpu_so); > > This looks correct to me but is causing problems. The above statement seems to get dropped in the generated asm ... at least on a PPC host: > > IN: > 0x00000000100005b4: cmpw cr3,r30,r29 > > OUT: [size=160] > 0x6041ad30: lwz r14,-4(r27) > 0x6041ad34: cmpwi cr7,r14,0 > 0x6041ad38: bne- cr7,0x6041adbc > 0x6041ad3c: ld r14,240(r27) <<< r30 > 0x6041ad40: ld r15,232(r27) <<< r31 > 0x6041ad44: cmpw cr7,r14,r15 <<< this is the TCG_COND_LTx code > 0x6041ad48: li r16,1 > 0x6041ad4c: li r0,0 > 0x6041ad50: isel r16,r16,r0,28 > 0x6041ad54: stw r16,576(r27) <<< store cpu_cr[LT] > 0x6041ad58: cmpw cr7,r14,r15 > 0x6041ad5c: li r16,1 > 0x6041ad60: li r0,0 > 0x6041ad64: isel r16,r16,r0,29 > 0x6041ad68: stw r16,580(r27) <<< store cpu_cr[GT] > 0x6041ad6c: cmplw cr7,r14,r15 > 0x6041ad70: li r14,1 > 0x6041ad74: li r0,0 > 0x6041ad78: isel r14,r14,r0,30 > 0x6041ad7c: stw r14,584(r27) <<< store cpu_cr[EQ] > 0x6041ad80: .long 0x0 > 0x6041ad84: .long 0x0 > > Richard: any ideas or hints on how to proceed? Check the op dumps and make sure it's there. If it is, but is getting discarded somewhere further down the pipeline, then try and get me a testcase. > This is a very nice cleanup ... but it oversteers just a little. For some CR logical instructions, the generated code can produce non-zero bits in the i32 cr variable in places other than the LSB. > For example, consider crnand, which produces the following on a PPC host: > > IN: > 0x0000000010000578: crnand 4*cr7+so,4*cr7+lt,4*cr7+eq > > OUT: [size=112] > 0x6041a630: lwz r14,-4(r27) > 0x6041a634: cmpwi cr7,r14,0 > 0x6041a638: bne- cr7,0x6041a68c > 0x6041a63c: lwz r14,640(r27) > 0x6041a640: lwz r15,648(r27) > 0x6041a644: nand r14,r14,r15 > 0x6041a648: andi. r14,r14,1 > 0x6041a64c: stw r14,652(r27) > 0x6041a650: .long 0x0 > 0x6041a654: .long 0x0 > 0x6041a658: .long 0x0 > 0x6041a65c: .long 0x0 > > The host nand operation will always produce an i32 value that has 1s in bits 0-30, since they are presumably zero. A brute-force fix would be to add a tcg_gen_andi_i32(D,D,1) to your macro. But I think this is required only for a subset of the > instructions (crnand, crnor, creqv, crorc). Note that since most hosts don't have nand, the combination nand x,y,z and x.x,1 would be better represented with and x,y,z xor x,x,1 r~