Lines Matching full:which
11 LLVM supports instructions which are well-defined in the presence of threads and
39 which ensures that every volatile load and store happens and is performed in the
59 section specifically goes into the one optimizer restriction which applies in
60 concurrent environments, which gets a bit more of an extended description
98 expecting, which can lead to undefined behavior down the line. (This example is
102 Note that speculative loads are allowed; a load which is part of a race returns
120 A ``fence`` provides Acquire and/or Release ordering which is not part
131 therefore an instruction which is wider than the target natively supports can be
149 NotAtomic is the obvious, a load or store which is not atomic. (This isn't
180 which writes to surrounding bytes. (If you are writing a backend for an
181 architecture which cannot satisfy these restrictions and cares about
199 "safe" languages which need to guarantee that the generated code never
209 narrows a store, or stores a value which would not be stored otherwise. Some
218 unordered loads and unordered stores, a load cannot see a value which was
221 instructions (or an instruction which does multiple memory operations, like
237 If you are writing a frontend which uses this directly, use with caution. The
239 only used in a pattern which you know is correct. Generally, these would
240 either be used for atomic operations which do not protect other memory (like
248 operations are unlikely to be used in ways which would make those
267 If you are writing a frontend which uses this directly, use with caution.
281 a simple implementation, most architectures provide a barrier which is strong
296 If you are writing a frontend which uses this directly, use with caution.
316 barrier (for fences and operations which both read and write memory).
322 If you are writing a frontend which uses this directly, use with caution.
343 the gcc-compatible ``__sync_*`` builtins which do not specify otherwise.
362 fence after the stores; which is preferred varies by architecture.
369 * ``isSimple()``: A load or store which is not volatile or atomic. This is
372 * ``isUnordered()``: A load or store which is not volatile and at most
377 that they return true for any operation which is volatile or at least
408 MemoryDependencyAnalysis (which is also used by other passes like GVN).
418 On architectures which use barrier instructions for all atomic ordering (like
442 ``setMaxAtomicSizeInBitsSupported`` (which defaults to 0).
457 which take some sort of exclusive lock on a cache line (``LDREX`` and ``STREX``
510 There are four generic functions, which can be called with data of any size or
518 There are also size-specialized versions of the above functions, which can only
529 Finally there are some read-modify-write functions, which are only available in
543 - They support all sizes and alignments -- including those which cannot be
548 compiler-support library, as they have state which must be shared amongst all
556 produced by an old compiler (which will have called the ``__atomic_*`` function)
557 interoperates with code produced by the new compiler (which will use native
573 Some CPUs support multiple instruction sets which can be switched back and forth
574 on function-call boundaries. For example, MIPS supports the MIPS16 ISA, which
583 function which on older CPUs contains a "magically-restartable" atomic sequence
584 (which looks atomic so long as there's only one CPU), and contains actual atomic
586 be provided on any architecture, if all CPUs which are missing atomic
592 Some targets (like RISCV) support a ``+forced-atomics`` target feature, which
640 On AArch64, a variant of the __sync_* routines is used which contain the memory
642 whether the single-instruction atomic operations which were introduced as part