From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atFi6-0003ht-Bj for qemu-devel@nongnu.org; Thu, 21 Apr 2016 10:36:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atFi3-0007M6-5w for qemu-devel@nongnu.org; Thu, 21 Apr 2016 10:36:02 -0400 Received: from mail-lf0-x22b.google.com ([2a00:1450:4010:c07::22b]:35384) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atFi2-0007KS-RO for qemu-devel@nongnu.org; Thu, 21 Apr 2016 10:35:59 -0400 Received: by mail-lf0-x22b.google.com with SMTP id c126so61965272lfb.2 for ; Thu, 21 Apr 2016 07:35:58 -0700 (PDT) References: <1460666749-24452-1-git-send-email-sergey.fedorov@linaro.org> <1460666749-24452-5-git-send-email-sergey.fedorov@linaro.org> <87inzfvwiq.fsf@linaro.org> <5714F7C4.6040306@gmail.com> <87h9eyx2e9.fsf@linaro.org> <57151EA4.7040309@gmail.com> From: Sergey Fedorov Message-ID: <5718E54B.1020602@gmail.com> Date: Thu, 21 Apr 2016 17:35:55 +0300 MIME-Version: 1.0 In-Reply-To: <57151EA4.7040309@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: Sergey Fedorov , qemu-devel@nongnu.org, Paolo Bonzini , Peter Crosthwaite , Richard Henderson , =?UTF-8?Q?Andreas_F=c3=a4rber?= On 18/04/16 20:51, Sergey Fedorov wrote: > On 18/04/16 20:17, Alex Bennée wrote: >> Sergey Fedorov writes: >>> On 18/04/16 17:09, Alex Bennée wrote: >>>> Sergey Fedorov writes: >>>>> diff --git a/cpu-exec.c b/cpu-exec.c >>> (snip) >>>>> @@ -507,14 +510,12 @@ int cpu_exec(CPUState *cpu) >>>>> } >>>>> tb_lock(); >>>>> tb = tb_find_fast(cpu); >>>>> - /* Note: we do it here to avoid a gcc bug on Mac OS X when >>>>> - doing it in tb_find_slow */ >>>> Is this still true? Would it make more sense to push the patching down >>>> to the gen_code? >>> This comment comes up to the commit: >>> >>> commit 1538800276aa7228d74f9d00bf275f54dc9e9b43 >>> Author: bellard >>> Date: Mon Dec 19 01:42:32 2005 +0000 >>> >>> workaround for gcc bug on PowerPC >>> >>> >>> It was added more than ten years ago. Anyway, now this code is here not >>> because of the bug: we need to reset 'next_tb' which is a local variable >>> in cpu_exec(). Personally, I don't think it would be neater to hide it >>> into gen_code(). Do you have some thoughts on how we could benefit from >>> doing so? BTW, I had a feeling that it may be useful to reorganize >>> cpu_exec() a bit, although I don't have a solid idea of how to do this >>> so far. >> I'm mainly eyeing the tb_lock/unlock which would be nice to push further >> down the call chain if we can, especially if the need to lock >> tb_find_fast can be removed later on. > Yes, it would be nice to possibly have all tb_lock/unlock() calls (or at > least their pairs) in the same block. There is a lot to be thought over :) It's not so simple because tb_find_fast() is also called in replay mode to find a TB for cpu_exec_nocache()... I'm not sure it's worth touching it now. Although it may be possible to improve the code structure of cpu_exec() in some other way. (It's really scary, indeed.) Actually, I've been keeping that in mind for some time. Do you think if MTTCG would benefit from some cpu_exec() refactoring to make it more clear and easy to understand? Kind regards, Sergey