On 25/05/16 22:25, Alex Bennée wrote: > Richard Henderson <r...@twiddle.net> writes: >> On 05/24/2016 10:18 AM, Pranith Kumar wrote: >>> Signed-off-by: Pranith Kumar <bobby.pr...@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
