Re: [Qemu-devel] [RFC PATCH 2/3] tcg: Add support for fence generation in x86 backend

[Sergey Fedorov <serge.fdrv@gmail.com>]

On 25/05/16 22:25, Alex Bennée wrote:
> Richard Henderson <rth@twiddle.net> writes:
>> On 05/24/2016 10:18 AM, Pranith Kumar wrote:
>>> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
>>> ---
>>>  tcg/i386/tcg-target.h     | 1 +
>>>  tcg/i386/tcg-target.inc.c | 9 +++++++++
>>>  tcg/tcg-opc.h             | 2 +-
>>>  tcg/tcg.c                 | 1 +
>>>  4 files changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
>>> index 92be341..93ea42e 100644
>>> --- a/tcg/i386/tcg-target.h
>>> +++ b/tcg/i386/tcg-target.h
>>> @@ -100,6 +100,7 @@ extern bool have_bmi1;
>>>  #define TCG_TARGET_HAS_muls2_i32        1
>>>  #define TCG_TARGET_HAS_muluh_i32        0
>>>  #define TCG_TARGET_HAS_mulsh_i32        0
>>> +#define TCG_TARGET_HAS_fence            1
>> This has to be defined for all hosts.
>>
>> The default implementation should be a function call into tcg-runtime.c that
>> calls smp_mb().
> That would solves the problem of converting the various backends
> piecemeal - although obviously we should move to all backends having
> "native" support ASAP. However by introducing expensive substitute
> functions we will slow down the translations as each front end is
> expanded to translate the target barrier ops.

I think it would better not to defer native support for the operation.
It should be relatively simple instruction. Otherwise we could wind up
deferring this indefinitely.

> Should we make the emitting of the function call/TCGop conditional on
> MTTCG being enabled? If we are running in round-robin mode there is no
> need to issue any fence operations.

Good idea.

Kind regards,
Sergey