On Wed, Jun 1, 2016 at 5:17 PM, Richard Henderson wrote:
>
> Because x86 has a strong memory model.
>
> It does not require barriers to keep normal loads and stores in order. The
> primary reason for the *fence instructions is to order the "non-temporal"
> memory operations that are part of the S
On 06/01/2016 11:49 AM, Pranith Kumar wrote:
On Tue, May 31, 2016 at 4:27 PM, Richard Henderson wrote:
On 05/31/2016 11:39 AM, Pranith Kumar wrote:
+case INDEX_op_mb:
+tcg_out_mb(s);
You need to look at the barrier type and DTRT. In particular, the Linux
smp_rmb and smp_wmb ty
On Tue, May 31, 2016 at 4:27 PM, Richard Henderson wrote:
> On 05/31/2016 11:39 AM, Pranith Kumar wrote:
>>
>> +case INDEX_op_mb:
>> +tcg_out_mb(s);
>
>
> You need to look at the barrier type and DTRT. In particular, the Linux
> smp_rmb and smp_wmb types need not emit any code.
These
On 05/31/2016 11:39 AM, Pranith Kumar wrote:
+case INDEX_op_mb:
+tcg_out_mb(s);
You need to look at the barrier type and DTRT. In particular, the Linux
smp_rmb and smp_wmb types need not emit any code.
+{ INDEX_op_mb, { "r" } },
You certainly do *not* need the constant ar
Generate mfence instruction on SSE2 enabled processors. For older
processors, generate a 'lock orl $0,0(%esp)' instruction which has
similar ordering semantics.
Signed-off-by: Pranith Kumar
[rth: Check for sse2, fallback to locked memory op otherwise.]
Signed-off-by: Richard Henderson
Signed-of
