Lines Matching refs:store

342  (1) Write (or store) memory barriers.
352      A CPU can be viewed as committing a sequence of store operations to the
618 for load-store control dependencies, as in the following example:
628 loads from 'a', and the store to 'b' with other stores to 'b', with
669 Now there is no conditional between the load from 'a' and the store to
722 between the load from variable 'a' and the store to variable 'b'.  It is
729 	BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */
739 identical, as noted earlier, the compiler could pull this store outside
808       between the prior load and the subsequent store, and this
890 Firstly, write barriers act as partial orderings on store operations.
1009 	  prior to the store of C        \      +-------+       |       |
1271 store to X and that CPU 2's load from Y in some sense preceded CPU 3's
1272 store to Y.  The question is then "Can CPU 3's load from X return 0?"
1274 Because CPU 2's load from X in some sense came after CPU 1's store, it
1302 of loads, it does not guarantee to order CPU 1's store.  Therefore, if
1303 this example runs on a system where CPUs 1 and 2 share a store buffer
1454  (*) Similarly, the compiler is within its rights to omit a store entirely
1462 	/* Code that does not store to variable a. */
1466      it might well omit the second store.  This would come as a fatal
1474 	/* Code that does not store to variable a. */
1574      and "store tearing," in which a single large access is replaced by
1576      16-bit store instructions with 7-bit immediate fields, the compiler
1577      might be tempted to use two 16-bit store-immediate instructions to
1578      implement the following 32-bit store:
1584      than two instructions to build the constant and then store it.
1587      this optimization in a volatile store.  In the absence of such bugs,
1588      use of WRITE_ONCE() prevents store tearing in the following example:
1592      Use of packed structures can also result in load and store tearing,
1611      load tearing on 'foo1.b' and store tearing on 'foo2.b'.  READ_ONCE()
2179 Furthermore, following a store by a load from the same device obviates the need
2180 for the mmiowb(), because the load forces the store to complete before the load
2466 The store to the data register might happen after the second store to the
2529      deferral if it so wishes; to flush a store, a load from the same location
2625 Although any particular load or store may not actually appear outside of the
2633 generate load and store operations which then go into the queue of memory
2864      mechanisms may alleviate this - once the store has actually hit the cache