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.ekstr...@intel.com>
On Mon, Sep 22, 2014 at 12:13 PM, Jason Ekstrand <ja...@jlekstrand.net>
wrote:
>
>
> On Mon, Sep 22, 2014 at 11:51 AM, Matt Turner <matts...@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@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
