On 21/04/16 18:55, Alex Bennée wrote: > Sergey Fedorov <[email protected]> writes: > >> On 18/04/16 20:51, Sergey Fedorov wrote: >>> On 18/04/16 20:17, Alex Bennée wrote: >>>> Sergey Fedorov <[email protected]> writes: >>>>> On 18/04/16 17:09, Alex Bennée wrote: >>>>>> Sergey Fedorov <[email protected]> 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 <bellard@c046a42c-6fe2-441c-8c8c-71466251a162> >>>>> 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. > If the locking is pushed into tb_find_fast or further down is this an > issue?
We would have to pass 'next_tb' (or 'last_tb' and 'tb_exit' after cleaning it up) if we move TB chaining code to tb_find_fast(). But tb_find_fast() is also called in replay mode to find a TB for cpu_exec_nocache() where we don't bother with TB chaining... Do you think it would be fine to make those changes? Kind regards, Sergey
