Lines Matching refs:compiler
104 appears to be maintained. Similarly, the compiler may also arrange the
205 and WRITE_ONCE() are required to prevent compiler mischief. Please
231 (*) It _must_not_ be assumed that the compiler will do what you want
233 WRITE_ONCE(). Without them, the compiler is within its rights to
281 in a given bitfield are protected by different locks, the compiler's
323 What is required is some way of intervening to instruct the compiler and the
627 READ_ONCE(), the compiler might combine the load from 'a' with other
631 Worse yet, if the compiler is able to prove (say) that the value of
672 assembly code even after all compiler optimizations have been applied.
697 The initial READ_ONCE() is still required to prevent the compiler from
701 otherwise the compiler might be able to guess the value and again remove
713 If MAX is defined to be 1, then the compiler knows that (q % MAX) is
714 equal to zero, in which case the compiler is within its rights to
739 identical, as noted earlier, the compiler could pull this store outside
750 always true, the compiler can transform this example as following,
756 This example underscores the need to ensure that the compiler cannot
758 the compiler to actually emit code for a given load, it does not force
759 the compiler to use the results.
809 conditional must involve the prior load. If the compiler is able
814 (*) Control dependencies require that the compiler avoid reordering the
1329 The Linux kernel has an explicit compiler barrier function that prevents the
1330 compiler from moving the memory accesses either side of it to the other side:
1341 (*) Prevents the compiler from reordering accesses following the
1346 (*) Within a loop, forces the compiler to load the variables used
1354 (*) The compiler is within its rights to reorder loads and stores
1363 Prevent both the compiler and the CPU from doing this as follows:
1371 (*) The compiler is within its rights to merge successive loads from
1372 the same variable. Such merging can cause the compiler to "optimize"
1386 Use READ_ONCE() to prevent the compiler from doing this to you:
1391 (*) The compiler is within its rights to reload a variable, for example,
1392 in cases where high register pressure prevents the compiler from
1393 keeping all data of interest in registers. The compiler might
1410 Again, use READ_ONCE() to prevent the compiler from doing this:
1415 Note that if the compiler runs short of registers, it might save
1418 single-threaded code, so you need to tell the compiler about cases
1421 (*) The compiler is within its rights to omit a load entirely if it knows
1422 what the value will be. For example, if the compiler can prove that
1433 gets rid of a load and a branch. The problem is that the compiler
1436 compiler's proof will be erroneous. Use READ_ONCE() to tell the
1437 compiler that it doesn't know as much as it thinks it does:
1442 But please note that the compiler is also closely watching what you
1449 Then the compiler knows that the result of the "%" operator applied
1450 to MAX will always be zero, again allowing the compiler to optimize
1454 (*) Similarly, the compiler is within its rights to omit a store entirely
1456 Again, the compiler assumes that the current CPU is the only one
1457 storing into the variable, which can cause the compiler to do the
1465 The compiler sees that the value of variable 'a' is already zero, so
1470 Use WRITE_ONCE() to prevent the compiler from making this sort of
1477 (*) The compiler is within its rights to reorder memory accesses unless
1493 There is nothing to prevent the compiler from transforming
1529 You should assume that the compiler can move READ_ONCE() and
1535 WRITE_ONCE(), the compiler need only forget the contents of the
1536 indicated memory locations, while with barrier() the compiler must
1538 cached in any machine registers. Of course, the compiler must also
1542 (*) The compiler is within its rights to invent stores to a variable,
1550 The compiler might save a branch by optimizing this as follows:
1567 The compiler can also invent loads. These are usually less
1576 16-bit store instructions with 7-bit immediate fields, the compiler
1608 volatile markings, the compiler would be well within its rights to
1625 Please note that these compiler barriers have no direct effect on the CPU,
1642 All memory barriers except the data dependency barriers imply a compiler
1643 barrier. Data dependencies do not impose any additional compiler ordering.
1645 Aside: In the case of data dependencies, the compiler would be expected
1648 the C specification that the compiler may not speculate the value of b
1650 tmp = a[b]; ). There is also the problem of a compiler reloading b after
1655 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1667 memory operations appear to a device by prohibiting both the compiler and the
1677 insert anything more than a compiler barrier in a UP compilation.
1879 the reordering, not the compiler. If the compiler (or, for
1937 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2312 compiler barrier, thus making sure the compiler emits the instructions in the
2416 However, having a clever CPU or a clever compiler creates a potential problem
2418 device in the requisite order if the CPU or the compiler thinks it is more
2585 Similarly, it has to be assumed that compiler might reorder the instruction
2910 The compiler may also combine, discard or defer elements of the sequence before