Patch for PR libgomp/37938, IA64 specific.
H.J. Lu
hjl.tools@gmail.com
Fri Nov 7 21:18:00 GMT 2008
On Fri, Nov 7, 2008 at 10:57 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Nov 7, 2008 at 10:35 AM, Steve Ellcey <sje@cup.hp.com> wrote:
>>
>> On Thu, 2008-11-06 at 17:12 -0800, H.J. Lu wrote:
>>
>>> static inline void gomp_mutex_unlock (gomp_mutex_t *mutex)
>>> {
>>> int val = __sync_lock_test_and_set (mutex, 0);
>>> if (__builtin_expect (val > 1, 0))
>>> gomp_mutex_unlock_slow (mutex);
>>> }
>>>
>>> should work as long as mutex isn't updated with release or
>>> unordered semantics prior to this function call. Who else
>>> have updated mutux? What semantics are they using?
>>
>> Isn't the lock done with release semantics? gomp_mutex_lock
>> calls __sync_bool_compare_and_swap and sync_compare_and_swap<mode> in
>> sync.md generates a cmpxchg.rel instruction.
>>
>
> According to ia64 psABI, __sync_bool_compare_and_swap and
> sync_compare_and_swap<mode>
> should have full barrier. That means they should use cmpxchg.acq,
> which is icc 11.0 generates.
>
I think cmpxchg.rel is typo:
(define_insn "cmpxchg_rel_<mode>"
[(set (match_operand:DI 0 "gr_register_operand" "=r")
(zero_extend:DI
(match_operand:I124MODE 1 "not_postinc_memory_operand" "+S")))
(set (match_dup 1)
(unspec:I124MODE
[(match_dup 1)
(match_operand:DI 2 "ar_ccv_reg_operand" "")
(match_operand:I124MODE 3 "gr_register_operand" "r")]
UNSPEC_CMPXCHG_ACQ))]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
""
"cmpxchg<modesuffix>.rel %0 = %1, %3, %2"
[(set_attr "itanium_class" "sem")])
(define_insn "cmpxchg_rel_di"
[(set (match_operand:DI 0 "gr_register_operand" "=r")
(match_operand:DI 1 "not_postinc_memory_operand" "+S"))
(set (match_dup 1)
(unspec:DI [(match_dup 1)
(match_operand:DI 2 "ar_ccv_reg_operand" "")
(match_operand:DI 3 "gr_register_operand" "r")]
UNSPEC_CMPXCHG_ACQ))]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
""
"cmpxchg8.rel %0 = %1, %3, %2"
[(set_attr "itanium_class" "sem")])
--
H.J.
More information about the Gcc-patches
mailing list