From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THKBz-00070R-GX for qemu-devel@nongnu.org; Thu, 27 Sep 2012 15:56:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THKBy-0006ST-Hj for qemu-devel@nongnu.org; Thu, 27 Sep 2012 15:56:15 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:61885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THKBy-0006SP-9R for qemu-devel@nongnu.org; Thu, 27 Sep 2012 15:56:14 -0400 Received: by pbbrp2 with SMTP id rp2so4091755pbb.4 for ; Thu, 27 Sep 2012 12:56:13 -0700 (PDT) Sender: Richard Henderson Message-ID: <5064AF5B.2050704@twiddle.net> Date: Thu, 27 Sep 2012 12:56:11 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1348766113-18373-1-git-send-email-aurelien@aurel32.net> <1348766113-18373-14-git-send-email-aurelien@aurel32.net> In-Reply-To: <1348766113-18373-14-git-send-email-aurelien@aurel32.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Aurelien Jarno Cc: qemu-devel@nongnu.org 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. > 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. r~