[llvm] [AtomicExpand] Let targets keep the release fence out of the reservation (PR #214867)

[Josef Schlehofer via llvm-commits]

BKPepe wrote:

Reworked from an unconditional hoist to an opt-in `TargetLowering` hook, after being told the constraint is a target property and does not belong in the generic pass. That was right, and it turned out to matter concretely: ARM emits a `DMB` in the sunk position and its monitor survives one, so the unconditional version would have charged it for a constraint it does not have.

`fenceClearsLoadLinkedReservation()` defaults to false. For targets that leave it there the `UseUnconditionalReleaseBarrier` condition is unchanged from before, so their codegen is preserved.

I can now answer the impact question with numbers rather than a caveat. Built with `LLVM_TARGETS_TO_BUILD="PowerPC;ARM;AArch64;RISCV;Mips;Sparc"`: 75 test failures with the change and the same 75 without it, identical lists, all pre-existing on `main` in this build configuration.

The description also has the before/after block diagram, since the obvious first objection is that the fence now runs on the path where nothing is stored.

https://github.com/llvm/llvm-project/pull/214867