Add full compiler barriers to any fence that lacked a compiler barrier. (mono/mono...
authorJay Krell <jaykrell@microsoft.com>
Fri, 13 Dec 2019 21:49:15 +0000 (13:49 -0800)
committerAlexander Köplinger <alex.koeplinger@outlook.com>
Fri, 13 Dec 2019 21:49:15 +0000 (22:49 +0100)
commit91d5b44577fe567bb0988df635b62df9c3fc6117
treec1f289ebb21663a6288e0b88cd041c992556466d
parent69ff23de6205705d9119db853a0578339bdb90d4
Add full compiler barriers to any fence that lacked a compiler barrier. (mono/mono#18177)

A compiler barrier generates no code.
It "only" inhibits certain compiler optimizations, which I do not consider
particularly worrisome, as most code is "fully" optimized, and
compiler barriers are relatively rare.

It could be a concern in code paths that greatly benefit
from compiler optimizations and for which barriers greatly
inhibits the compiler.

I would further suggest, though it is not here, that any compiler
half barrier (read, write) be a compiler full barrier instead,
as they sound pretty cheap, so simplify.

Similar cannot be said about CPU barriers.
They do not always generate code, but when they do, it can cost.

This is follow-up from https://github.com/mono/mono/pull/17849#issuecomment-556273801
https://github.com/mono/mono/pull/17849#issuecomment-557661604.

Commit migrated from https://github.com/mono/mono/commit/e76fb5dbf92c34a944f6e3d5654a51661acbf6d8
src/mono/mono/utils/mono-memory-model.h