RFC: linux-aarch64 and LSE support

[dean.long at oracle.com]

On 9/20/22 4:15 AM, Andrew Haley wrote:
>  > (I'm also not getting the point about a lack of
>  > barrier-ordered-after, but maybe I'm just confused.)
> 
> The lack of barrier-ordered-after is why we need a fence after all ops
> for conservative.
> 
> (In fact we don't: all Arm hardware in existence works without the
> trailing fence. And probably always will. But the Arm spec allows
> reordering, even though available hardware doesn't. This is annoying,
> but that's life.)

I'm probably missing something too, because I don't understand this 
either.  If the atomic op has acquire-release semantics, then this part 
of the spec seems like it means no fence after is required:

(older spec)
"At least one of RW1 and RW2 is generated by an atomic instruction with 
both Acquire and
Release semantics."

(newer spec)
"RW1 is a memory write effect W1 and is generated by an atomic 
instruction with both Acquire
and Release semantics." (if the cas succeeded)

"RW1 is a memory read effect R1, except a Tag-Check-read, and is 
generated by an instruction
with Acquire or AcquirePC semantics." (if the cas failed)

Also, since "Barrier-ordered-before" describes when RW1 "happened 
before" RW2 (or RW2 "happened after" RW1, right?), I don't understand 
why an additional "barrier-ordered-after" would be desired.

dl