This is an archive of the discontinued LLVM Phabricator instance.

Erase fence insertion from SelectionDAGBuilder.cpp (NFC)
ClosedPublic

Authored by morisset on Sep 23 2014, 3:59 PM.

Details

Summary

Backends can use setInsertFencesForAtomic to signal to the middle-end that
montonic is the only memory ordering they can accept for
stores/loads/rmws/cmpxchg. The code lowering those accesses with a stronger
ordering to fences + monotonic accesses is currently living in
SelectionDAGBuilder.cpp. In this patch I propose moving this logic out of it
for several reasons:

  • There is lots of redundancy to avoid: extremely similar logic already exists in AtomicExpand.
  • The current code in SelectionDAGBuilder does not use any target-hooks, it does the same transformation for every backend that requires it
  • As a result it is plain *unsound*, as it was apparently designed for ARM. It happens to mostly work for the other targets because they are extremely conservative, but Power for example had to switch to AtomicExpand to be able to use lwsync safely (see r218331).
  • Because it produces IR-level fences, it cannot be made sound ! This is noted in the C++11 standard (section 29.3, page 1140):
Fences cannot, in general, be used to restore sequential consistency for atomic
operations with weaker ordering semantics.

It can also be seen by the following example (called IRIW in the litterature):

atomic<int> x = y = 0;
int r1, r2, r3, r4;
Thread 0:
  x.store(1);
Thread 1:
  y.store(1);
Thread 2:
  r1 = x.load();
  r2 = y.load();
Thread 3:
  r3 = y.load();
  r4 = x.load();

r1 = r3 = 1 and r2 = r4 = 0 is impossible as long as the accesses are all seq_cst.
But if they are lowered to monotonic accesses, no amount of fences can prevent it..

This patch does three things (I could cut it into parts, but then some of them
would not be tested/testable, please tell me if you would prefer that):

  • it provides a default implementation for emitLeadingFence/emitTrailingFence in

terms of IR-level fences, that mimic the original logic of SelectionDAGBuilder.
As we saw above, this is unsound, but the best that can be done without knowing
the targets well (and there is a comment warning about this risk).

  • it then switches Mips/Sparc/XCore to use AtomicExpand, relying on this default

implementation (that exactly replicates the logic of SelectionDAGBuilder, so no
functional change)

  • it finally erase this logic from SelectionDAGBuilder as it is dead-code.

Ideally, each target would define its own override for emitLeading/TrailingFence
using target-specific fences, but I do not know the Sparc/Mips/XCore memory model
well enough to do this, and they appear to be dealing fine with the ARM-inspired
default expansion for now (probably because they are overly conservative, as
Power was). If anyone wants to compile fences more agressively on these
platforms, the long comment should make it clear why he should first override
emitLeading/TrailingFence.

Diff Detail

Event Timeline

morisset updated this revision to Diff 14022.Sep 23 2014, 3:59 PM
morisset retitled this revision from to Erase fence insertion from SelectionDAGBuilder.cpp (NFC).
morisset updated this object.
morisset edited the test plan for this revision. (Show Details)
morisset added reviewers: jfb, t.p.northover.
morisset added a subscriber: Unknown Object (MLST).
jfb added a reviewer: rkotler.Oct 3 2014, 2:49 PM
jfb edited edge metadata.Oct 3 2014, 2:55 PM

I added @rkotler to the review for MIPS. I'm not sure if anyone on Sparc/XCore can comment. Overall this is NFC, so no big issue.

The change looks good overall.

include/llvm/Target/TargetLowering.h
976

The FIXME should probably say how to fix this (or maybe point it out in the code below), and then suggest that the asserts be added back.

984

You can create a doxygen group for these functions, start with @{ in the comment for emitLeading, and after emitTrailing close with }@.

test/CodeGen/XCore/atomic.ll
26

Why does the barrier move?

morisset added inline comments.Oct 3 2014, 3:56 PM
include/llvm/Target/TargetLowering.h
976

I tried to give the solution just above "Backends should override this method to produce target-specific intrinsic for their fence". I do not see what more I can say, apart from maybe "look at what the ARM backend does".

984

Ok, thanks for the trick, I will do that.

test/CodeGen/XCore/atomic.ll
26

I am not entirely sure, but both placements appear correct. So while I agree it is surprising and slightly troubling, I decided to go ahead as I could not find any other case when it happens. I suspect it is just some the instruction scheduler that must pick differently between two valid choices, for some reason (The first lowering happens a bit earlier in the pipeline so maybe this cause some other pass in-between to change subtly its behaviour ?)

morisset updated this revision to Diff 14583.Oct 8 2014, 11:02 AM
morisset edited edge metadata.

Rebase on trunk + use doxygen trick suggested by jfb

jfb accepted this revision.Oct 8 2014, 12:03 PM
jfb edited edge metadata.

lgtm, though I'd like to make sure @t.p.northover agrees since he was involved in the discussion that led to this patch.

This revision is now accepted and ready to land.Oct 8 2014, 12:03 PM
t.p.northover accepted this revision.Oct 16 2014, 12:51 PM
t.p.northover edited edge metadata.

Yep, this looks sensible to me too. Sorry I didn't get around to looking sooner.

Tim.

morisset closed this revision.Oct 16 2014, 1:45 PM
morisset updated this revision to Diff 15046.

Closed by commit rL219957 (authored by @morisset).