From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THKtQ-00058A-JK for qemu-devel@nongnu.org; Thu, 27 Sep 2012 16:41:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THKtM-0004sd-5r for qemu-devel@nongnu.org; Thu, 27 Sep 2012 16:41:08 -0400 Received: from hall.aurel32.net ([88.191.126.93]:48978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THKtL-0004sO-Md for qemu-devel@nongnu.org; Thu, 27 Sep 2012 16:41:04 -0400 Date: Thu, 27 Sep 2012 22:37:11 +0200 From: Aurelien Jarno Message-ID: <20120927203711.GO20151@ohm.aurel32.net> References: <1348766113-18373-1-git-send-email-aurelien@aurel32.net> <1348766113-18373-14-git-send-email-aurelien@aurel32.net> <5064AF5B.2050704@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <5064AF5B.2050704@twiddle.net> Subject: Re: [Qemu-devel] [PATCH 13/13] tcg: rework TCG ops flags List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On Thu, Sep 27, 2012 at 12:56:11PM -0700, Richard Henderson wrote: > On 09/27/2012 10:15 AM, Aurelien Jarno wrote: > > - TCG_OPF_CALL_CLOBBER: The op clobber the call registers. They are > > freed before emitting the op. > > - TCG_OPF_SIDE_EFFECTS: The op is not removed if the returned value > > if not used. It can trigger exception and thus globals are > > synchronized before emitting the op. > > - TCG_OPF_READ_GLOBALS: The op can read globals but not write them, > > and thus globals are synchronized before emitting the op. > > - TCG_OPF_WRITE_GLOBALS: The op can read and write globals, and thus > > globals are saved back to their canonical location before emitting > > the op. > > This is more or less exactly the flag breakup I was talking about for calls. > > I don't agree with SIDE_EFFECTS implying exceptions. How can "br" cause an > exception? Or for that matter "st_i32", recalling that we're not storing > to guest memory. That's exactly why SIDE_EFFECTS has been removed from this op in the previous patch. I think it implies exception, because I don't see why an op shouldn't be removed otherwise (remember ops without outputs are never removed). > > Note: While this is restoring the possibility to map a memory address > > using both a global and accessing it through ld/st, this reduces the > > performances of targets generating a lot of ld/st op. Given it is > > currently technically not allowed, we might instead change the TCG > > documentation to make that clear. > > Yes, I think we should. I can't see that this is something that we > should *ever* do. > Ok, then the documentation should be fixed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net