[Mesa-dev] [PATCH 06/12] mesa: Consolidate likely/unlikely macros.

[Matt Turner]

---
 src/gallium/include/pipe/p_compiler.h     | 45 +------------------------------
 src/mapi/u_compiler.h                     | 10 -------
 src/mesa/drivers/dri/i915/intel_context.h | 10 -------
 src/util/macros.h                         | 32 ++++++++++++++++++++++
 4 files changed, 33 insertions(+), 64 deletions(-)

diff --git a/src/gallium/include/pipe/p_compiler.h b/src/gallium/include/pipe/p_compiler.h
index 939fb06..4ed6a4b 100644
--- a/src/gallium/include/pipe/p_compiler.h
+++ b/src/gallium/include/pipe/p_compiler.h
@@ -30,6 +30,7 @@
 
 
 #include "c99_compat.h" /* inline, __func__, etc. */
+#include "../../../util/macros.h"
 
 #include "p_config.h"
 
@@ -204,50 +205,6 @@ void _ReadWriteBarrier(void);
 
 #endif
 
-
-/* You should use these macros to mark if blocks where the if condition
- * is either likely to be true, or unlikely to be true.
- *
- * This will inform human readers of this fact, and will also inform
- * the compiler, who will in turn inform the CPU.
- *
- * CPUs often start executing code inside the if or the else blocks
- * without knowing whether the condition is true or not, and will have
- * to throw the work away if they find out later they executed the
- * wrong part of the if.
- *
- * If these macros are used, the CPU is more likely to correctly predict
- * the right path, and will avoid speculatively executing the wrong branch,
- * thus not throwing away work, resulting in better performance.
- *
- * In light of this, it is also a good idea to mark as "likely" a path
- * which is not necessarily always more likely, but that will benefit much
- * more from performance improvements since it is already much faster than
- * the other path, or viceversa with "unlikely".
- *
- * Example usage:
- * if(unlikely(do_we_need_a_software_fallback()))
- *    do_software_fallback();
- * else
- *    render_with_gpu();
- *
- * The macros follow the Linux kernel convention, and more examples can
- * be found there.
- *
- * Note that profile guided optimization can offer better results, but
- * needs an appropriate coverage suite and does not inform human readers.
- */
-#ifndef likely
-#  if defined(__GNUC__)
-#    define likely(x)   __builtin_expect(!!(x), 1)
-#    define unlikely(x) __builtin_expect(!!(x), 0)
-#  else
-#    define likely(x)   (x)
-#    define unlikely(x) (x)
-#  endif
-#endif
-
-
 /**
  * Static (compile-time) assertion.
  * Basically, use COND to dimension an array.  If COND is false/zero the
diff --git a/src/mapi/u_compiler.h b/src/mapi/u_compiler.h
index b305beb..3364ecd 100644
--- a/src/mapi/u_compiler.h
+++ b/src/mapi/u_compiler.h
@@ -9,14 +9,4 @@
 #  define INLINE inline
 #endif
 
-#ifndef likely
-#  if defined(__GNUC__)
-#    define likely(x)   __builtin_expect(!!(x), 1)
-#    define unlikely(x) __builtin_expect(!!(x), 0)
-#  else
-#    define likely(x)   (x)
-#    define unlikely(x) (x)
-#  endif
-#endif
-
 #endif /* _U_COMPILER_H_ */
diff --git a/src/mesa/drivers/dri/i915/intel_context.h b/src/mesa/drivers/dri/i915/intel_context.h
index fccf821..0f315da 100644
--- a/src/mesa/drivers/dri/i915/intel_context.h
+++ b/src/mesa/drivers/dri/i915/intel_context.h
@@ -95,16 +95,6 @@ extern void intelFallback(struct intel_context *intel, GLbitfield bit,
 #define INTEL_WRITE_FULL  0x2
 #define INTEL_READ        0x4
 
-#ifndef likely
-#ifdef __GNUC__
-#define likely(expr) (__builtin_expect(expr, 1))
-#define unlikely(expr) (__builtin_expect(expr, 0))
-#else
-#define likely(expr) (expr)
-#define unlikely(expr) (expr)
-#endif
-#endif
-
 struct intel_sync_object {
    struct gl_sync_object Base;
 
diff --git a/src/util/macros.h b/src/util/macros.h
index c65ce8a..db5b31a 100644
--- a/src/util/macros.h
+++ b/src/util/macros.h
@@ -37,6 +37,38 @@
 #  define __builtin_expect(x, y) (x)
 #endif
 
+/* You should use these macros to mark if blocks where the if condition
+ * is either likely to be true, or unlikely to be true.
+ *
+ * This will inform human readers of this fact, and will also inform
+ * the compiler, who will in turn inform the CPU.
+ *
+ * CPUs often start executing code inside the if or the else blocks
+ * without knowing whether the condition is true or not, and will have
+ * to throw the work away if they find out later they executed the
+ * wrong part of the if.
+ *
+ * If these macros are used, the CPU is more likely to correctly predict
+ * the right path, and will avoid speculatively executing the wrong branch,
+ * thus not throwing away work, resulting in better performance.
+ *
+ * In light of this, it is also a good idea to mark as "likely" a path
+ * which is not necessarily always more likely, but that will benefit much
+ * more from performance improvements since it is already much faster than
+ * the other path, or viceversa with "unlikely".
+ *
+ * Example usage:
+ * if(unlikely(do_we_need_a_software_fallback()))
+ *    do_software_fallback();
+ * else
+ *    render_with_gpu();
+ *
+ * The macros follow the Linux kernel convention, and more examples can
+ * be found there.
+ *
+ * Note that profile guided optimization can offer better results, but
+ * needs an appropriate coverage suite and does not inform human readers.
+ */
 #ifndef likely
 #  ifdef HAVE___BUILTIN_EXPECT
 #    define likely(x)   __builtin_expect(!!(x), 1)
-- 
1.8.5.5