Several different target backends end up implementing compiler-only
barrier pseudo-instructions which eventually expand into an assembly
comment.
These come from for example C's atomic_signal_fence, C++'s
std::atomic_signal_fence, or Rust's compiler_barrier which are all
documented to not result in assembly instructions. While emitting a
fence instruction (or equivalent) is not incorrect within usual memory
models, it is inefficient. Depending on the target configuration, these
usually turn into atomic_fence before SelectionDAG (with syncscope of
"singlethread"), where they are then turned first into a target-specific
ISD node, and then into a pseudo-instruction which prints as a comment.
Most LLVM Target backends seem to have copied a MEMBARRIER
target-specific ISD node, so every new LLVM target needs to replicate
all these parts to get the same behaviour. Some targets don't do this,
and end up emitting fence instructions without paying attention to the
syncscope fence argument.
LLVM, however, has target-independent machine opcodes, which have a
variety of uses in LLVM's backend code. This patch adds a
COMPILER_BARRIER target-independent opcode to represent a compiler-only
barrier, which does not generate instructions. This opcode still
contains information about the syncscope and ordering of the original
atomic_fence, so that backend-specific optimisations still have this
information.
This patch also refactors existing instances of target-specific
MEMBARRIERs to use the new target-independent COMPILER_BARRIER.
Sorry, I missed this comment