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

Jason Ekstrand jason at jlekstrand.net
Mon Sep 22 12:19:08 PDT 2014


I won't claim to have reviewed the automake bits and I haven't built it.
However, the C bits in 2, 3, 5, and 6 are Reviewed-by: Jason Ekstrand <
jason.ekstrand at intel.com>

On Mon, Sep 22, 2014 at 12:13 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:

>
>
> 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/adb2d3f5/attachment-0001.html>


More information about the mesa-dev mailing list