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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- 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:37:36 -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> <87k32timyd dot fsf at tassilo dot jf dot intel dot com>
On Mon, Nov 17, 2014 at 12:36 PM, Andi Kleen <andi@firstfloor.org> wrote:
> "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.
>
If you can extract a small testcase, it will be much easier to review.
--
H.J.