> From: Richard Henderson <r...@redhat.com> > Date: Tue, 12 Jun 2012 23:04:02 +0200
> On 2012-05-31 22:58, Hans-Peter Nilsson wrote: > > +(define_expand "atomic_compare_and_swap<mode>" > > + [(match_operand:SI 0 "register_operand") > > + (match_operand:BWD 1 "register_operand") > > + (match_operand:BWD 2 "memory_operand") > > + (match_operand:BWD 3 "general_operand") > > + (match_operand:BWD 4 "register_operand") > > + (match_operand 5) > > + (match_operand 6) > > + (match_operand 7)] > > + "" > > +{ > > + if (<MODE>mode != QImode && TARGET_TRAP_UNALIGNED_ATOMIC) > > + cris_emit_trap_for_misalignment (operands[2]); > > + > > + expand_mem_thread_fence (INTVAL (operands[6])); > > + emit_insn (gen_cris_atomic_compare_and_swap<mode>_1 (operands[0], > > + operands[1], > > + operands[2], > > + operands[3], > > + operands[4])); > > + expand_mem_thread_fence (INTVAL (operands[6])); > > Unlike the old sync optabs, you don't necessarily need both fences. > Operands 6 and 7 tell you what fences you need. Putting a lot of trust onto users and libraries there, to choose the right model... > Please have a look at the arm, alpha, or rs6000 versions, where we > have <cpu>_{pre,post}_atomic_barrier (model) functions. Yeah, I took the safe route here, always emitting a fence, this being an area where you don't want subtle bugs. Lots of safety at a negligible performance cost. I don't have second thoughts, but I did look *again* at those ports. brgds, H-P