Lines Matching refs:compiler

26 	compiler from deducing the resulting pointer value.  Please see
28 	for an example where the compiler can in fact deduce the exact
38 	The compiler simply knows too much about integral values to
56 	"(x-(uintptr_t)x)" for char* pointers.	The compiler is within its
95 	explained, if the two pointers are equal, the compiler could
103 	Because the compiler now knows that the value of "p" is exactly
118 		compiler knows that the pointer is NULL, you had better
120 		non-equal, the compiler is none the wiser.  Therefore,
125 		Since there are no subsequent dereferences, the compiler
183 	-	The pointers are not equal *and* the compiler does
186 		will normally prevent the compiler from knowing too much.
188 		However, please note that if the compiler knows that the
191 		compiler needs to deduce the value of the pointer.
193 -	Disable any value-speculation optimizations that your compiler
201 	ordered systems (such as ARM or Power).  Choose your compiler
249 			/* The compiler decides that q->c is same as p->c. */
259 to some reordering from the compiler and CPUs is beside the point.
307 			/* The compiler decides that q->c is same as p->c. */
321 other pointer, the compiler normally has no clue what the value of the
322 first pointer might be.  This lack of knowledge prevents the compiler
325 should prevent the compiler from guessing the value.
327 But without rcu_dereference(), the compiler knows more than you might
360 Because the compiler can see all stores to "gp", it knows that the only
362 on the other.  The comparison in reader() therefore tells the compiler
364 compiler to make the return values independent of the load from "gp",
434 pointers, which can result in "interesting" bugs due to compiler
442 If register pressure is high, the compiler might optimize "p" out