Lines Matching refs:compiler
141 appears to be maintained. Similarly, the compiler may also arrange the
246 Whether on DEC Alpha or not, the READ_ONCE() also prevents compiler
271 (*) It _must_not_ be assumed that the compiler will do what you want
273 WRITE_ONCE(). Without them, the compiler is within its rights to
321 in a given bitfield are protected by different locks, the compiler's
363 What is required is some way of intervening to instruct the compiler and the
627 Documentation/RCU/rcu_dereference.txt file: The compiler can and does
671 the compiler's ignorance from breaking your code.
705 are optional! Without the READ_ONCE(), the compiler might combine the
707 the compiler might combine the store to 'b' with other stores to 'b'.
710 Worse yet, if the compiler is able to prove (say) that the value of
751 assembly code even after all compiler optimizations have been applied.
776 The initial READ_ONCE() is still required to prevent the compiler from
780 otherwise the compiler might be able to guess the value and again remove
792 If MAX is defined to be 1, then the compiler knows that (q % MAX) is
793 equal to zero, in which case the compiler is within its rights to
818 identical, as noted earlier, the compiler could pull this store outside
829 always true, the compiler can transform this example as following,
835 This example underscores the need to ensure that the compiler cannot
837 the compiler to actually emit code for a given load, it does not force
838 the compiler to use the results.
853 compiler cannot reorder volatile accesses and also cannot reorder
855 of reasoning, the compiler might compile the two writes to 'b' as
899 conditional must involve the prior load. If the compiler is able
904 (*) Control dependencies require that the compiler avoid reordering the
1522 The Linux kernel has an explicit compiler barrier function that prevents the
1523 compiler from moving the memory accesses either side of it to the other side:
1534 (*) Prevents the compiler from reordering accesses following the
1539 (*) Within a loop, forces the compiler to load the variables used
1547 (*) The compiler is within its rights to reorder loads and stores
1556 Prevent both the compiler and the CPU from doing this as follows:
1564 (*) The compiler is within its rights to merge successive loads from
1565 the same variable. Such merging can cause the compiler to "optimize"
1579 Use READ_ONCE() to prevent the compiler from doing this to you:
1584 (*) The compiler is within its rights to reload a variable, for example,
1585 in cases where high register pressure prevents the compiler from
1586 keeping all data of interest in registers. The compiler might
1603 Again, use READ_ONCE() to prevent the compiler from doing this:
1608 Note that if the compiler runs short of registers, it might save
1611 single-threaded code, so you need to tell the compiler about cases
1614 (*) The compiler is within its rights to omit a load entirely if it knows
1615 what the value will be. For example, if the compiler can prove that
1626 gets rid of a load and a branch. The problem is that the compiler
1629 compiler's proof will be erroneous. Use READ_ONCE() to tell the
1630 compiler that it doesn't know as much as it thinks it does:
1635 But please note that the compiler is also closely watching what you
1642 Then the compiler knows that the result of the "%" operator applied
1643 to MAX will always be zero, again allowing the compiler to optimize
1647 (*) Similarly, the compiler is within its rights to omit a store entirely
1649 Again, the compiler assumes that the current CPU is the only one
1650 storing into the variable, which can cause the compiler to do the
1658 The compiler sees that the value of variable 'a' is already zero, so
1663 Use WRITE_ONCE() to prevent the compiler from making this sort of
1670 (*) The compiler is within its rights to reorder memory accesses unless
1686 There is nothing to prevent the compiler from transforming
1722 You should assume that the compiler can move READ_ONCE() and
1728 WRITE_ONCE(), the compiler need only forget the contents of the
1729 indicated memory locations, while with barrier() the compiler must
1731 cached in any machine registers. Of course, the compiler must also
1735 (*) The compiler is within its rights to invent stores to a variable,
1743 The compiler might save a branch by optimizing this as follows:
1760 The compiler can also invent loads. These are usually less
1769 16-bit store instructions with 7-bit immediate fields, the compiler
1801 volatile markings, the compiler would be well within its rights to
1818 Please note that these compiler barriers have no direct effect on the CPU,
1835 All memory barriers except the data dependency barriers imply a compiler
1836 barrier. Data dependencies do not impose any additional compiler ordering.
1838 Aside: In the case of data dependencies, the compiler would be expected
1841 the C specification that the compiler may not speculate the value of b
1843 tmp = a[b]; ). There is also the problem of a compiler reloading b after
1848 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1862 compiler and the CPU from reordering them.
1871 compiler barrier in a UP compilation.
2060 the reordering, not the compiler. If the compiler (or, for
2118 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2504 compiler barrier, thus making sure the compiler emits the instructions in the
2527 However, having a clever CPU or a clever compiler creates a potential problem
2529 device in the requisite order if the CPU or the compiler thinks it is more
2696 Similarly, it has to be assumed that compiler might reorder the instruction
3025 The compiler may also combine, discard or defer elements of the sequence before