Lines Matching refs:compiler
104 appears to be maintained. Similarly, the compiler may also arrange the
205 is required to prevent compiler mischief. Please note that you
231 (*) It _must_not_ be assumed that the compiler will do what you want with
233 ACCESS_ONCE(), the compiler is within its rights to do all sorts
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
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 ACCESS_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
749 Because the second condition is always true, the compiler can transform
755 This example underscores the need to ensure that the compiler cannot
757 the compiler to actually emit code for a given load, it does not force
758 the compiler to use the results.
807 conditional must involve the prior load. If the compiler
812 (*) Control dependencies require that the compiler avoid reordering the
1327 The Linux kernel has an explicit compiler barrier function that prevents the
1328 compiler from moving the memory accesses either side of it to the other side:
1339 (*) Prevents the compiler from reordering accesses following the
1344 (*) Within a loop, forces the compiler to load the variables used
1351 (*) The compiler is within its rights to reorder loads and stores
1360 Prevent both the compiler and the CPU from doing this as follows:
1368 (*) The compiler is within its rights to merge successive loads from
1369 the same variable. Such merging can cause the compiler to "optimize"
1383 Use ACCESS_ONCE() to prevent the compiler from doing this to you:
1388 (*) The compiler is within its rights to reload a variable, for example,
1389 in cases where high register pressure prevents the compiler from
1390 keeping all data of interest in registers. The compiler might
1407 Again, use ACCESS_ONCE() to prevent the compiler from doing this:
1412 Note that if the compiler runs short of registers, it might save
1415 single-threaded code, so you need to tell the compiler about cases
1418 (*) The compiler is within its rights to omit a load entirely if it knows
1419 what the value will be. For example, if the compiler can prove that
1430 rid of a load and a branch. The problem is that the compiler will
1432 updating variable 'a'. If variable 'a' is shared, then the compiler's
1433 proof will be erroneous. Use ACCESS_ONCE() to tell the compiler
1439 But please note that the compiler is also closely watching what you
1446 Then the compiler knows that the result of the "%" operator applied
1447 to MAX will always be zero, again allowing the compiler to optimize
1451 (*) Similarly, the compiler is within its rights to omit a store entirely
1453 Again, the compiler assumes that the current CPU is the only one
1454 storing into the variable, which can cause the compiler to do the
1462 The compiler sees that the value of variable 'a' is already zero, so
1467 Use ACCESS_ONCE() to prevent the compiler from making this sort of
1474 (*) The compiler is within its rights to reorder memory accesses unless
1490 There is nothing to prevent the compiler from transforming
1525 You should assume that the compiler can move ACCESS_ONCE() past
1529 is more selective: With ACCESS_ONCE(), the compiler need only forget
1531 the compiler must discard the value of all memory locations that
1533 the compiler must also respect the order in which the ACCESS_ONCE()s
1536 (*) The compiler is within its rights to invent stores to a variable,
1544 The compiler might save a branch by optimizing this as follows:
1561 The compiler can also invent loads. These are usually less
1570 16-bit store instructions with 7-bit immediate fields, the compiler
1602 the compiler would be well within its rights to implement these three
1618 Please note that these compiler barriers have no direct effect on the CPU,
1635 All memory barriers except the data dependency barriers imply a compiler
1636 barrier. Data dependencies do not impose any additional compiler ordering.
1638 Aside: In the case of data dependencies, the compiler would be expected to
1641 that the compiler may not speculate the value of b (eg. is equal to 1) and load
1643 problem of a compiler reloading b after having loaded a[b], thus having a newer
1647 SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
1659 memory operations appear to a device by prohibiting both the compiler and the
1669 insert anything more than a compiler barrier in a UP compilation.
1867 the reordering, not the compiler. If the compiler (or, for
1948 (RELEASE equivalent) will act as compiler barriers only. So if memory or I/O
2357 compiler barrier, thus making sure the compiler emits the instructions in the
2461 However, having a clever CPU or a clever compiler creates a potential problem
2463 device in the requisite order if the CPU or the compiler thinks it is more
2630 Similarly, it has to be assumed that compiler might reorder the instruction
2954 The compiler may also combine, discard or defer elements of the sequence before