From patchwork Mon May 3 19:54:50 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Blue Swirl X-Patchwork-Id: 51524 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 1ED4CB7D20 for ; Tue, 4 May 2010 05:57:17 +1000 (EST) Received: from localhost ([127.0.0.1]:36791 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O91lS-0004sq-FG for incoming@patchwork.ozlabs.org; Mon, 03 May 2010 15:57:14 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O91jE-0004G6-Gb for qemu-devel@nongnu.org; Mon, 03 May 2010 15:54:56 -0400 Received: from [140.186.70.92] (port=36479 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O91jC-0004FF-LT for qemu-devel@nongnu.org; Mon, 03 May 2010 15:54:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O91jA-0002Yd-Ib for qemu-devel@nongnu.org; Mon, 03 May 2010 15:54:54 -0400 Received: from mail-px0-f173.google.com ([209.85.212.173]:46383) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O91jA-0002YL-8l for qemu-devel@nongnu.org; Mon, 03 May 2010 15:54:52 -0400 Received: by pxi19 with SMTP id 19so1302124pxi.4 for ; Mon, 03 May 2010 12:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=YC4Nb9wMHkgC4nlKAUEKNRCsY2mk1wwYIM4zQQ1xWps=; b=Jx2UE8NPDWpJJ2EmgIm1nxxqxdKuXfxIVCAywmhYSViR0WlUD9XsrTJZuuY41HTmBd oA/MfDbYzvDVVkBm14oFzUEDPPFVdfvXLIadP0H1BpEc4MGL/bqsN84vaoWvUfMUNUcm pBJcGuv5jj9aX5ZHNsu7ev3Wn47I7uaQJCKzY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YR86lh0/OcgZ2Jt7tpai9GllVA8XbjVl91Ol2cV3cY9ZB2U2svoiUG9QGvmxuVlR2g cgTDkByrTAPrud2oAkeHylhrdZYDA44zjLT38QT5Rl4kmegZcUTg474HnTgWeJteSlMJ +h2n4LCuElUsdNPbjXYS1oDaErlyN8Nzr00vY= MIME-Version: 1.0 Received: by 10.140.56.21 with SMTP id e21mr3815981rva.46.1272916490986; Mon, 03 May 2010 12:54:50 -0700 (PDT) Received: by 10.140.128.21 with HTTP; Mon, 3 May 2010 12:54:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 May 2010 22:54:50 +0300 Message-ID: From: Blue Swirl To: Igor Kovalenko X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: qemu-devel Subject: [Qemu-devel] Re: sparc64 lazy conditional codes evaluation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 5/3/10, Igor Kovalenko wrote: > On Mon, May 3, 2010 at 11:24 PM, Blue Swirl wrote: > > On 5/3/10, Igor Kovalenko wrote: > >> Hi! > >> > >> There is an issue with lazy conditional codes evaluation where > >> we return from trap handler with mismatching conditionals. > >> > >> I seldom reproduce it here when dragging qemu window while > >> machine is working through silo initialization. I use gentoo minimal cd > >> install-sparc64-minimal-20100322.iso but I think anything with silo boot > >> would experience the same. Once in a while it would report crc error, > >> unable to open cd partition or it would fail to decompress image. > > > > I think I've also seen this. > > > >> Pattern that fails appears to require a sequence of compare insn > >> possibly followed by a few instructions which do not touch conditionals, > >> then conditional branch insn. If it happens that we trap while processing > >> conditional branch insn so it is restarted after return from trap then > >> seldom conditional codes are calculated incorrectly. > >> > >> I cannot point to exact cause but it appears that after trap return > >> we may have CC_OP and CC_SRC* mismatch somewhere, > >> since adding more cond evaluation flushes over the code helps. > >> > >> We already tried doing flush more frequently and it is still not > >> complete, so the question is how to finally do this once and right :) > >> > >> Obviously I do not get the design of lazy evaluation right, but > >> the following list appears to be good start. Plan is to prepare > >> a change to qemu and find a way to test it. > >> > >> 1. Since SPARC* is a RISC CPU it seems to be not profitable to > >> use DisasContext->cc_op to predict if flags should be not evaluated > >> due to overriding insn. Instead we can drop cc_op from disassembler > >> context and simplify code to only use cc_op from env. > > > > Not currently, but in the future we may use that to do even lazier > > flags computation. For example the sequence 'cmp x, y; bne target' > > could be much more optimal by changing the branch to do the > > comparison. Here's an old unfinished patch to do some of this. > > > >> Another point is that we always write to env->cc_op when > >> translating *cc insns > >> This should solve any issue with dc->cc_op prediction going > >> out of sync with env->cc_op and cpu_cc_src* > > > > I think this is what is happening now. > > > >> 2. We must flush lazy evaluation back to CC_OP_FLAGS in a few cases when > >> a. conditional code is required by insn (like addc, cond branch etc.) > >> - here we can optimize by evaluating specific bits (carry?) > >> - not sure if it works in case we have two cond consuming insns, > >> where first needs carry another needs the rest of flags > > > > Here's another patch to optimize C flag handling. It doesn't pass my > > tests though. > > > >> b. CCR is read by rdccr (helper_rdccr) > >> - have to compute all flags > >> c. trap occurs and we prepare trap level context (saving pstate) > >> - have to compute all flags > >> d. control goes out of tcg runtime (so gdbstub reads correct value from env) > >> - have to compute all flags > > > > Fully agree. > > > Cool > > Still I'd propose to kill dc->cc_op, find a reliable way to test it > and then add it back possibly with more optimizations. > I'm lost in the code up to the point where I believe we need to > save/restore cc_op and cpu_cc* while switching trap levels. I'd think this should do the trick: diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index b27778b..94921cd 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -3506,6 +3506,8 @@ void do_interrupt(CPUState *env) } tsptr = cpu_tsptr(env); + helper_compute_psr(); + tsptr->tstate = ((uint64_t)GET_CCR(env) << 32) | ((env->asi & 0xff) << 24) | ((env->pstate & 0xf3f) << 8) | GET_CWP64(env);