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
626 Documentation/RCU/rcu_dereference.txt file: The compiler can and does
670 the compiler's ignorance from breaking your code.
704 are optional! Without the READ_ONCE(), the compiler might combine the
706 the compiler might combine the store to 'b' with other stores to 'b'.
709 Worse yet, if the compiler is able to prove (say) that the value of
750 assembly code even after all compiler optimizations have been applied.
775 The initial READ_ONCE() is still required to prevent the compiler from
779 otherwise the compiler might be able to guess the value and again remove
791 If MAX is defined to be 1, then the compiler knows that (q % MAX) is
792 equal to zero, in which case the compiler is within its rights to
817 identical, as noted earlier, the compiler could pull this store outside
828 always true, the compiler can transform this example as following,
834 This example underscores the need to ensure that the compiler cannot
836 the compiler to actually emit code for a given load, it does not force
837 the compiler to use the results.
852 compiler cannot reorder volatile accesses and also cannot reorder
854 of reasoning, the compiler might compile the two writes to 'b' as
898 conditional must involve the prior load. If the compiler is able
903 (*) Control dependencies require that the compiler avoid reordering the
1521 The Linux kernel has an explicit compiler barrier function that prevents the
1522 compiler from moving the memory accesses either side of it to the other side:
1533 (*) Prevents the compiler from reordering accesses following the
1538 (*) Within a loop, forces the compiler to load the variables used
1546 (*) The compiler is within its rights to reorder loads and stores
1555 Prevent both the compiler and the CPU from doing this as follows:
1563 (*) The compiler is within its rights to merge successive loads from
1564 the same variable. Such merging can cause the compiler to "optimize"
1578 Use READ_ONCE() to prevent the compiler from doing this to you:
1583 (*) The compiler is within its rights to reload a variable, for example,
1584 in cases where high register pressure prevents the compiler from
1585 keeping all data of interest in registers. The compiler might
1602 Again, use READ_ONCE() to prevent the compiler from doing this:
1607 Note that if the compiler runs short of registers, it might save
1610 single-threaded code, so you need to tell the compiler about cases
1613 (*) The compiler is within its rights to omit a load entirely if it knows
1614 what the value will be. For example, if the compiler can prove that
1625 gets rid of a load and a branch. The problem is that the compiler
1628 compiler's proof will be erroneous. Use READ_ONCE() to tell the
1629 compiler that it doesn't know as much as it thinks it does:
1634 But please note that the compiler is also closely watching what you
1641 Then the compiler knows that the result of the "%" operator applied
1642 to MAX will always be zero, again allowing the compiler to optimize
1646 (*) Similarly, the compiler is within its rights to omit a store entirely
1648 Again, the compiler assumes that the current CPU is the only one
1649 storing into the variable, which can cause the compiler to do the
1657 The compiler sees that the value of variable 'a' is already zero, so
1662 Use WRITE_ONCE() to prevent the compiler from making this sort of
1669 (*) The compiler is within its rights to reorder memory accesses unless
1685 There is nothing to prevent the compiler from transforming
1721 You should assume that the compiler can move READ_ONCE() and
1727 WRITE_ONCE(), the compiler need only forget the contents of the
1728 indicated memory locations, while with barrier() the compiler must
1730 cached in any machine registers. Of course, the compiler must also
1734 (*) The compiler is within its rights to invent stores to a variable,
1742 The compiler might save a branch by optimizing this as follows:
1759 The compiler can also invent loads. These are usually less
1768 16-bit store instructions with 7-bit immediate fields, the compiler
1800 volatile markings, the compiler would be well within its rights to
1817 Please note that these compiler barriers have no direct effect on the CPU,
1834 All memory barriers except the data dependency barriers imply a compiler
1835 barrier. Data dependencies do not impose any additional compiler ordering.
1837 Aside: In the case of data dependencies, the compiler would be expected
1840 the C specification that the compiler may not speculate the value of b
1842 tmp = a[b]; ). There is also the problem of a compiler reloading b after
1847 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1861 compiler and the CPU from reordering them.
1870 compiler barrier in a UP compilation.
2044 the reordering, not the compiler. If the compiler (or, for
2102 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2419 compiler barrier, thus making sure the compiler emits the instructions in the
2442 However, having a clever CPU or a clever compiler creates a potential problem
2444 device in the requisite order if the CPU or the compiler thinks it is more
2646 Similarly, it has to be assumed that compiler might reorder the instruction
2975 The compiler may also combine, discard or defer elements of the sequence before