Lines Matching refs:compiler
139 appears to be maintained. Similarly, the compiler may also arrange the
244 Whether on DEC Alpha or not, the READ_ONCE() also prevents compiler
269 (*) It _must_not_ be assumed that the compiler will do what you want
271 WRITE_ONCE(). Without them, the compiler is within its rights to
319 in a given bitfield are protected by different locks, the compiler's
361 What is required is some way of intervening to instruct the compiler and the
634 Documentation/RCU/rcu_dereference.rst file: The compiler can and does break
678 the compiler's ignorance from breaking your code.
713 are optional! Without the READ_ONCE(), the compiler might combine the
715 the compiler might combine the store to 'b' with other stores to 'b'.
718 Worse yet, if the compiler is able to prove (say) that the value of
759 assembly code even after all compiler optimizations have been applied.
784 The initial READ_ONCE() is still required to prevent the compiler from
788 otherwise the compiler might be able to guess the value and again remove
800 If MAX is defined to be 1, then the compiler knows that (q % MAX) is
801 equal to zero, in which case the compiler is within its rights to
826 identical, as noted earlier, the compiler could pull this store outside
837 always true, the compiler can transform this example as following,
843 This example underscores the need to ensure that the compiler cannot
845 the compiler to actually emit code for a given load, it does not force
846 the compiler to use the results.
861 compiler cannot reorder volatile accesses and also cannot reorder
863 of reasoning, the compiler might compile the two writes to 'b' as
907 conditional must involve the prior load. If the compiler is able
912 (*) Control dependencies require that the compiler avoid reordering the
1528 The Linux kernel has an explicit compiler barrier function that prevents the
1529 compiler from moving the memory accesses either side of it to the other side:
1540 (*) Prevents the compiler from reordering accesses following the
1545 (*) Within a loop, forces the compiler to load the variables used
1553 (*) The compiler is within its rights to reorder loads and stores
1562 Prevent both the compiler and the CPU from doing this as follows:
1570 (*) The compiler is within its rights to merge successive loads from
1571 the same variable. Such merging can cause the compiler to "optimize"
1585 Use READ_ONCE() to prevent the compiler from doing this to you:
1590 (*) The compiler is within its rights to reload a variable, for example,
1591 in cases where high register pressure prevents the compiler from
1592 keeping all data of interest in registers. The compiler might
1609 Again, use READ_ONCE() to prevent the compiler from doing this:
1614 Note that if the compiler runs short of registers, it might save
1617 single-threaded code, so you need to tell the compiler about cases
1620 (*) The compiler is within its rights to omit a load entirely if it knows
1621 what the value will be. For example, if the compiler can prove that
1632 gets rid of a load and a branch. The problem is that the compiler
1635 compiler's proof will be erroneous. Use READ_ONCE() to tell the
1636 compiler that it doesn't know as much as it thinks it does:
1641 But please note that the compiler is also closely watching what you
1648 Then the compiler knows that the result of the "%" operator applied
1649 to MAX will always be zero, again allowing the compiler to optimize
1653 (*) Similarly, the compiler is within its rights to omit a store entirely
1655 Again, the compiler assumes that the current CPU is the only one
1656 storing into the variable, which can cause the compiler to do the
1664 The compiler sees that the value of variable 'a' is already zero, so
1669 Use WRITE_ONCE() to prevent the compiler from making this sort of
1676 (*) The compiler is within its rights to reorder memory accesses unless
1692 There is nothing to prevent the compiler from transforming
1728 You should assume that the compiler can move READ_ONCE() and
1734 WRITE_ONCE(), the compiler need only forget the contents of the
1735 indicated memory locations, while with barrier() the compiler must
1737 cached in any machine registers. Of course, the compiler must also
1741 (*) The compiler is within its rights to invent stores to a variable,
1749 The compiler might save a branch by optimizing this as follows:
1766 The compiler can also invent loads. These are usually less
1775 16-bit store instructions with 7-bit immediate fields, the compiler
1807 volatile markings, the compiler would be well within its rights to
1824 Please note that these compiler barriers have no direct effect on the CPU,
1841 All memory barriers except the address-dependency barriers imply a compiler
1842 barrier. Address dependencies do not impose any additional compiler ordering.
1844 Aside: In the case of address dependencies, the compiler would be expected
1847 the C specification that the compiler may not speculate the value of b
1849 tmp = a[b]; ). There is also the problem of a compiler reloading b after
1854 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1868 compiler and the CPU from reordering them.
1877 compiler barrier in a UP compilation.
2078 the reordering, not the compiler. If the compiler (or, for
2136 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2453 compiler barrier, thus making sure the compiler emits the instructions in the
2476 However, having a clever CPU or a clever compiler creates a potential problem
2478 device in the requisite order if the CPU or the compiler thinks it is more
2680 Similarly, it has to be assumed that compiler might reorder the instruction
2872 The compiler may also combine, discard or defer elements of the sequence before