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

Jason Ekstrand jason at jlekstrand.net
Mon Sep 22 12:13:48 PDT 2014


On Mon, Sep 22, 2014 at 11:51 AM, Matt Turner <mattst88 at gmail.com> wrote:

> ---
>  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"
>

Do we really need all those ".."s?  Seems to me like we should add
something to Makefile.am instead.


>
>  #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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140922/5320478b/attachment-0001.html>


More information about the mesa-dev mailing list