From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwhbo-0003k4-5s for qemu-devel@nongnu.org; Tue, 18 Oct 2016 23:32:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwhbk-0004pA-8G for qemu-devel@nongnu.org; Tue, 18 Oct 2016 23:32:04 -0400 Received: from mail-out.m-online.net ([2001:a60:0:28:0:1:25:1]:40177) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwhbk-0004o6-1Z for qemu-devel@nongnu.org; Tue, 18 Oct 2016 23:32:00 -0400 References: <20160927233049.5429-1-marex@denx.de> <20160927233049.5429-2-marex@denx.de> <20d61df8-b345-b097-8d9b-4a619849d86c@twiddle.net> <82ddeb82-768b-57d1-5962-a6940e5001c7@denx.de> <496742f4-af10-e029-62a2-f2c5054c9303@twiddle.net> <15816d97-1ea9-44df-01d0-10ee10430af2@denx.de> <5dacaa8f-646f-9bce-f362-1d5927893f73@denx.de> <434bbc7d-2a13-0253-0af0-151e43a89e16@twiddle.net> From: Marek Vasut Message-ID: Date: Wed, 19 Oct 2016 04:31:00 +0200 MIME-Version: 1.0 In-Reply-To: <434bbc7d-2a13-0253-0af0-151e43a89e16@twiddle.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/7] nios2: Add architecture emulation support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: Jeff Da Silva , Chris Wulff , Sandra Loosemore , Yves Vandervennet , Ley Foon Tan On 10/19/2016 03:24 AM, Richard Henderson wrote: > On 10/18/2016 03:05 PM, Marek Vasut wrote: >>>> Thanks, I hope this is fixed now, although I mostly special-case the >>>> R_ZERO handling throughout the code. Any writes to R_ZERO are now >>>> ignored and any usage is converted to mov/movi instructions where >>>> applicable. >>> >>> We've done that in the past, but in the end it is much cleaner to >>> minimize the number of places in which you have to check for R_ZERO. >> >> Isn't it a bit more performant if you generate as little TCG >> instructions as possible ? > > Well, yes and no. > > We're always going to run the tcg optimizers, so the resulting code > should be the same either way. I see, I'd have to dig deeper into the TCG. > Processing a little more data can be preferable to fewer branch > prediction failures. And the best way to avoid those is to not have the > branch at all. Especially when it's unlikely that the data will be > created in the first place. OK, but I need to make sure stores to ZERO register are ignored, right ? -- Best regards, Marek Vasut