[PATCH] D18201: Switch over targets to use AtomicExpandPass, and clean up target atomics code.
James Y Knight via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 15 15:39:12 PDT 2016
jyknight created this revision.
jyknight added subscribers: theraven, rnk, hfinkel, jfb, reames, joerg, llvm-commits.
Herald added subscribers: dsanders, jyknight, aemerson.
- Removed __sync_* libcall names from the default set of libcalls, so
that they cannot be accidentally invoked, unless requested. Targets
call initSyncLibcalls() to request them where they're supported and
required. (This is ARM and MIPS16 at the moment)
- Deleted 'enableAtomicExpand' TargetLowering function: it's always
enabled if you add the pass.
- Removed unnecessary selection dag expansions of ATOMIC_LOAD into
ATOMIC_CMP_SWAP and ATOMIC_STORE into ATOMIC_SWAP. Targets that
don't support atomic load/store should now be handled by the
translation in AtomicExpandPass into __atomic_load/__atomic_store,
rather than expanding into unnatural operations.
- Cleaned up conditionals in Target ISel code to handle too-large
atomic operations, where such operations are now expanded before
hitting the target's code.
ARM is the most complex target, as it's the only one which mixes all
the different options for atomic lowering, depending on the exact
subarchitecture and OS in use:
1) AtomicExpandPass expansion to LL/SC instructions, where available
natively (ARMv6+ in ARM mode, ARMv7+ in Thumb mode).
2) Passthrough of atomicrmw and cmpxchg in AtomicExpandPass, followed
by ISel expansion to __sync_* library calls, when native
instructions are not available, but when the OS does provides a
kernel-supported pseudo-atomic sequence. (This is Linux and Darwin,
at the moment).
3) AtomicExpandPass expansion to __atomic_* library calls, if neither
of the above are possible for a given size on the given CPU
So, naturally, ARM required the most changes here.
Also of note are the XCore changes. I removed all the code handing
ATOMIC_STORE/ATOMIC_LOAD, because as far as I can tell, XCore does not
have any cmpxchg support, and thus cannot claim to implement atomics
of any size.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 61284 bytes
Desc: not available
More information about the llvm-commits