---
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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
