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
623 Documentation/RCU/rcu_dereference.rst file: The compiler can and does
667 the compiler's ignorance from breaking your code.
701 are optional! Without the READ_ONCE(), the compiler might combine the
703 the compiler might combine the store to 'b' with other stores to 'b'.
706 Worse yet, if the compiler is able to prove (say) that the value of
747 assembly code even after all compiler optimizations have been applied.
772 The initial READ_ONCE() is still required to prevent the compiler from
776 otherwise the compiler might be able to guess the value and again remove
788 If MAX is defined to be 1, then the compiler knows that (q % MAX) is
789 equal to zero, in which case the compiler is within its rights to
814 identical, as noted earlier, the compiler could pull this store outside
825 always true, the compiler can transform this example as following,
831 This example underscores the need to ensure that the compiler cannot
833 the compiler to actually emit code for a given load, it does not force
834 the compiler to use the results.
849 compiler cannot reorder volatile accesses and also cannot reorder
851 of reasoning, the compiler might compile the two writes to 'b' as
895 conditional must involve the prior load. If the compiler is able
900 (*) Control dependencies require that the compiler avoid reordering the
1516 The Linux kernel has an explicit compiler barrier function that prevents the
1517 compiler from moving the memory accesses either side of it to the other side:
1528 (*) Prevents the compiler from reordering accesses following the
1533 (*) Within a loop, forces the compiler to load the variables used
1541 (*) The compiler is within its rights to reorder loads and stores
1550 Prevent both the compiler and the CPU from doing this as follows:
1558 (*) The compiler is within its rights to merge successive loads from
1559 the same variable. Such merging can cause the compiler to "optimize"
1573 Use READ_ONCE() to prevent the compiler from doing this to you:
1578 (*) The compiler is within its rights to reload a variable, for example,
1579 in cases where high register pressure prevents the compiler from
1580 keeping all data of interest in registers. The compiler might
1597 Again, use READ_ONCE() to prevent the compiler from doing this:
1602 Note that if the compiler runs short of registers, it might save
1605 single-threaded code, so you need to tell the compiler about cases
1608 (*) The compiler is within its rights to omit a load entirely if it knows
1609 what the value will be. For example, if the compiler can prove that
1620 gets rid of a load and a branch. The problem is that the compiler
1623 compiler's proof will be erroneous. Use READ_ONCE() to tell the
1624 compiler that it doesn't know as much as it thinks it does:
1629 But please note that the compiler is also closely watching what you
1636 Then the compiler knows that the result of the "%" operator applied
1637 to MAX will always be zero, again allowing the compiler to optimize
1641 (*) Similarly, the compiler is within its rights to omit a store entirely
1643 Again, the compiler assumes that the current CPU is the only one
1644 storing into the variable, which can cause the compiler to do the
1652 The compiler sees that the value of variable 'a' is already zero, so
1657 Use WRITE_ONCE() to prevent the compiler from making this sort of
1664 (*) The compiler is within its rights to reorder memory accesses unless
1680 There is nothing to prevent the compiler from transforming
1716 You should assume that the compiler can move READ_ONCE() and
1722 WRITE_ONCE(), the compiler need only forget the contents of the
1723 indicated memory locations, while with barrier() the compiler must
1725 cached in any machine registers. Of course, the compiler must also
1729 (*) The compiler is within its rights to invent stores to a variable,
1737 The compiler might save a branch by optimizing this as follows:
1754 The compiler can also invent loads. These are usually less
1763 16-bit store instructions with 7-bit immediate fields, the compiler
1795 volatile markings, the compiler would be well within its rights to
1812 Please note that these compiler barriers have no direct effect on the CPU,
1829 All memory barriers except the data dependency barriers imply a compiler
1830 barrier. Data dependencies do not impose any additional compiler ordering.
1832 Aside: In the case of data dependencies, the compiler would be expected
1835 the C specification that the compiler may not speculate the value of b
1837 tmp = a[b]; ). There is also the problem of a compiler reloading b after
1842 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1856 compiler and the CPU from reordering them.
1865 compiler barrier in a UP compilation.
2065 the reordering, not the compiler. If the compiler (or, for
2123 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2440 compiler barrier, thus making sure the compiler emits the instructions in the
2463 However, having a clever CPU or a clever compiler creates a potential problem
2465 device in the requisite order if the CPU or the compiler thinks it is more
2667 Similarly, it has to be assumed that compiler might reorder the instruction
2858 The compiler may also combine, discard or defer elements of the sequence before