This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add memory barriers to xbegin/xend/xabort
- From: Andi Kleen <andi at firstfloor dot org>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 17 Nov 2014 12:36:26 -0800
- Subject: Re: [PATCH] Add memory barriers to xbegin/xend/xabort
- Authentication-results: sourceware.org; auth=none
- References: <1414553479-21829-1-git-send-email-andi at firstfloor dot org> <CAFiYyc3TPoyghvPeDSRyOSEibDaKu4k-E56=XahwKOLAKhME_A at mail dot gmail dot com> <20141030060740 dot GJ3274 at tassilo dot jf dot intel dot com> <CAMe9rOqGxjNOPHmhdndEysMJG+aydRbb9UnE07V705P=N=yTyA at mail dot gmail dot com>
"H.J. Lu" <hjl.tools@gmail.com> writes:
> On Wed, Oct 29, 2014 at 11:07 PM, Andi Kleen <ak@linux.intel.com> wrote:
>>>
>>> Hmm, can't the insns themselves properly clobber/use memory?
>>
>> The transactions don't really use the memory. They just guard it,
>> like a lock.
>>
>> So the intrinsic doesn't know what memory is used inside the transaction,
>> but the accesses still cannot be moved out.
>>
>> I think a barrier is the only sensible option.
>>
>>> I suppose they are UNSPEC_VOLATILE anyway, right?
>>
>> That doesn't have any barrier semantics by itself, does it?
>>
>
> Do you have a testcase to show it makes a difference?
It fixed customer code. I currently don't have a separate
test case.
-Andi
--
ak@linux.intel.com -- Speaking for myself only