> From: Richard Henderson <[email protected]>
> 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
