Re: git: 2508372b7b46 - main - cdefs.h: Assume the compiler supports at least GNU C 3.0 extensions

On 6/20/24 7:41 PM, Warner Losh wrote:
> The branch main has been updated by imp:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=2508372b7b46117a9fb801b50624265d30888442
> 
> commit 2508372b7b46117a9fb801b50624265d30888442
> Author:     Warner Losh <imp@FreeBSD.org>
> AuthorDate: 2024-06-20 23:02:42 +0000
> Commit:     Warner Losh <imp@FreeBSD.org>
> CommitDate: 2024-06-21 02:41:08 +0000
> 
>      cdefs.h: Assume the compiler supports at least GNU C 3.0 extensions
>      
>      All compilers that can build FreeBSD binaries (as opposed to the entire
>      system) support at least gcc 9 (gcc, clang, tcc). Even pcc supports most
>      of the gcc 4.3 attributes. Make this file simpler by removing support
>      for pre-3.0 compilers.
>      
>      Reviewed by:            brooks
>      Differential Revision:  https://reviews.freebsd.org/D45653
>      Sponsored by:           Netflix
> ---
>   sys/sys/cdefs.h | 79 +--------------------------------------------------------
>   1 file changed, 1 insertion(+), 78 deletions(-)
> 
> diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h
> index 476c89d1dddb..88019819eb35 100644
> --- a/sys/sys/cdefs.h
> +++ b/sys/sys/cdefs.h
> @@ -389,45 +367,10 @@
>    */
>   #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901
>   #define	__restrict	restrict
> -#elif !__GNUC_PREREQ__(2, 95)
> -#define	__restrict
>   #endif
>   
> -/*
> - * GNU C version 2.96 adds explicit branch prediction so that
> - * the CPU back-end can hint the processor and also so that
> - * code blocks can be reordered such that the predicted path
> - * sees a more linear flow, thus improving cache behavior, etc.
> - *
> - * The following two macros provide us with a way to utilize this
> - * compiler feature.  Use __predict_true() if you expect the expression
> - * to evaluate to true, and __predict_false() if you expect the
> - * expression to evaluate to false.
> - *
> - * A few notes about usage:
> - *
> - *	* Generally, __predict_false() error condition checks (unless
> - *	  you have some _strong_ reason to do otherwise, in which case
> - *	  document it), and/or __predict_true() `no-error' condition
> - *	  checks, assuming you want to optimize for the no-error case.
> - *
> - *	* Other than that, if you don't know the likelihood of a test
> - *	  succeeding from empirical or other `hard' evidence, don't
> - *	  make predictions.
> - *
> - *	* These are meant to be used in places that are run `a lot'.
> - *	  It is wasteful to make predictions in code that is run
> - *	  seldomly (e.g. at subsystem initialization time) as the
> - *	  basic block reordering that this affects can often generate
> - *	  larger code.
> - */
> -#if __GNUC_PREREQ__(2, 96)
>   #define	__predict_true(exp)     __builtin_expect((exp), 1)
>   #define	__predict_false(exp)    __builtin_expect((exp), 0)
> -#else
> -#define	__predict_true(exp)     (exp)
> -#define	__predict_false(exp)    (exp)
> -#endif

I think the comment was worth keeping around.  You just need to modify
the start of it to "Modern compilers include explicit branch prediction..."
In particular, I think our current practice is still to apply prediction
hints rather conservatively.

-- 
John Baldwin