From nobody Tue Jul 02 18:05:52 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WD9nm54xkz5Nw81 for ; Tue, 02 Jul 2024 18:06:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WD9nm3Pj5z4Sxy for ; Tue, 2 Jul 2024 18:06:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-70671ecd334so3492066b3a.0 for ; Tue, 02 Jul 2024 11:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1719943563; x=1720548363; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oajtjtEmHNvTiPKZcEZaIQbENcUHZxrI8pUFeei2CUM=; b=KvmPDXJBshozxs4A+HuIXjyU2MD7mn43DIHDk3Bd7eoxHeKRrzqlf4TB50xMQ/NAH6 me7A8rtVO1P3NurGoGhjFRbHyP/nd3ZprIOW0XuaDrldu1vxni0IVXOF46/eB9/ZAfV/ hlSk7W9rJKtG/MfKRNiMmslTyq+WDSU1lSxAlTQDSQwXi0R18BjR49HBvvqAFEIpM8/p tGcPcjySwNxaU0wEbyK6CJ7PdMFv3Fl3giTRl2WlnNhTex6HB54X2Pjsjv+zQCOdUkLB SiPg85S+UlQ5WfnPEbynRBal1Pnsyq1ENV+Ewiv9HRpdr65hA2d8M7so4j4kalW9YShc 6WKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719943563; x=1720548363; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oajtjtEmHNvTiPKZcEZaIQbENcUHZxrI8pUFeei2CUM=; b=AnsBfTjZzRjmYsxpbgXUJNmai4D/wj9Eh7SuQz1uShHhwlYA+NgSS8A4AgIRsWtQba 3nUyPyPXyxBVwk3DCY1ixbyAFPvL9b75oHbETTw/Y+RKwl49LScZcg/dEC7v5gPF7XqZ xIEhHnnYhPkV4ftXnZbC7yKz7T9vSMPXkMmeWIDs/MYarc0wCIjqLFl/qXyCC3iAtmi/ T9bht2PRWZWLvumyLLacXGN0gwTD37sBu/cA6ApTfDw3/2fSIOiWlEXxGdDzQLqHF2NX i80ljKTthRsuK4+TGDmLXqnRw1ZT45EdQbTrvgMCuKYQr45lmSDMfZPYBIDhJwkTuPnj ysOA== X-Forwarded-Encrypted: i=1; AJvYcCXY5mTzy2il3JjpKBPrNibNHyPQA7kYIe6tt8NUX8Na4cbU+Q7PBukkaJNneQCawaIb4L/NeVsA2jdCT7Xqpehxgs6rWJJPLKB1APhyIcrWcA== X-Gm-Message-State: AOJu0YyfaS/KaRD3QsKPGeW++bRd7ifJUiekvmH7dh3fRkxxiV/4hVUl mqQb3eE1kPSzdvk9cU0Hhs4+jMFfdUJDp9GJvpXMtpVTS8+8+qEHMszJrODhJ02gJ7lIgdbTVyD ox+YSmaVpVzMMdmdVoCjyozLBrrigQQ1Xa1Ih9w== X-Google-Smtp-Source: AGHT+IEE17sFRi9TzTYwMrNcw1TxaWG3zLh0axevm8fd2AUKFugSVjzs9lCwhpMxxeIi0rMCspVDJ3CoOXxLcVKPVyA= X-Received: by 2002:a05:6a20:1584:b0:1bd:fe8:fc9a with SMTP id adf61e73a8af0-1bef60fc0demr12775061637.17.1719943563077; Tue, 02 Jul 2024 11:06:03 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 References: <202406210241.45L2fNU2056962@gitrepo.freebsd.org> <7ca0ab94-4d5e-405e-b178-84ef3d8ebc8d@FreeBSD.org> In-Reply-To: <7ca0ab94-4d5e-405e-b178-84ef3d8ebc8d@FreeBSD.org> From: Warner Losh Date: Tue, 2 Jul 2024 12:05:52 -0600 Message-ID: Subject: Re: git: 2508372b7b46 - main - cdefs.h: Assume the compiler supports at least GNU C 3.0 extensions To: John Baldwin Cc: Warner Losh , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001c839a061c479154" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4WD9nm3Pj5z4Sxy --0000000000001c839a061c479154 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey John, On Mon, Jul 1, 2024 at 3:49=E2=80=AFPM John Baldwin wrote= : > 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=3D2508372b7b46117a9fb801b50624265= d30888442 > > > > commit 2508372b7b46117a9fb801b50624265d30888442 > ... > > -/* > > - * 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 expressio= n > > - * 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. > That's a fair point I hadn't considered. https://reviews.freebsd.org/D45837 adds it back with some tiny tweaks to the language, justification, etc. Warner --0000000000001c839a061c479154 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey John,

On Mon, Jul 1, 2024 at 3:49= =E2=80=AFPM John Baldwin <jhb@freebsd= .org> wrote:
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=3D2508372b7b46117a9fb801b50624265d30888442<= /a>
>
> commit 2508372b7b46117a9fb801b50624265d30888442
> -/* > - * 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.=C2=A0 Use __predict_true() if you expect the exp= ression
> - * to evaluate to true, and __predict_false() if you expect the
> - * expression to evaluate to false.
> - *
> - * A few notes about usage:
> - *
> - *=C2=A0 =C2=A0* Generally, __predict_false() error condition checks = (unless
> - *=C2=A0 =C2=A0 =C2=A0you have some _strong_ reason to do otherwise, = in which case
> - *=C2=A0 =C2=A0 =C2=A0document it), and/or __predict_true() `no-error= ' condition
> - *=C2=A0 =C2=A0 =C2=A0checks, assuming you want to optimize for the n= o-error case.
> - *
> - *=C2=A0 =C2=A0* Other than that, if you don't know the likelihoo= d of a test
> - *=C2=A0 =C2=A0 =C2=A0succeeding from empirical or other `hard' e= vidence, don't
> - *=C2=A0 =C2=A0 =C2=A0make predictions.
> - *
> - *=C2=A0 =C2=A0* These are meant to be used in places that are run `a= lot'.
> - *=C2=A0 =C2=A0 =C2=A0It is wasteful to make predictions in code that= is run
> - *=C2=A0 =C2=A0 =C2=A0seldomly (e.g. at subsystem initialization time= ) as the
> - *=C2=A0 =C2=A0 =C2=A0basic block reordering that this affects can of= ten generate
> - *=C2=A0 =C2=A0 =C2=A0larger code.
> - */
> -#if __GNUC_PREREQ__(2, 96)
>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0__predict_true(exp)=C2=A0 =C2= =A0 =C2=A0__builtin_expect((exp), 1)
>=C2=A0 =C2=A0#define=C2=A0 =C2=A0 =C2=A0__predict_false(exp)=C2=A0 =C2= =A0 __builtin_expect((exp), 0)
> -#else
> -#define=C2=A0 =C2=A0 =C2=A0 __predict_true(exp)=C2=A0 =C2=A0 =C2=A0(e= xp)
> -#define=C2=A0 =C2=A0 =C2=A0 __predict_false(exp)=C2=A0 =C2=A0 (exp) > -#endif

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

adds it ba= ck with some tiny tweaks to the language, justification, etc.
Warner=C2=A0
--0000000000001c839a061c479154--