From owner-dev-commits-src-main@freebsd.org Tue Feb 2 21:54:28 2021 Return-Path: Delivered-To: dev-commits-src-main@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEEE053F039 for ; Tue, 2 Feb 2021 21:54:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DVdrM3nFHz4cwD for ; Tue, 2 Feb 2021 21:54:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1612302865; bh=xyKlfDaYlG0bCBCgJPbA/qFFbKVbPb0UETp593PjlGA=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QJJ/Wy8+Lr2UWqtbF2xNPbn+M9Imnl1oRved95ZHKTq6fuZgH1Vme8fIG1mAugyaQ10pwmAAw1KbWDuzcQTMqjp8LH2j70Et+U1zi2fdwaSDnp4c/t1w/SC56aGvvuKDPHyGGzefr2Jl2h2ke0/4Iy2KtVfPruQsh7+uPDVUwyqjFl7e9lIldS3i+o+D/JAkmzE8/vsDUWvocjpiTRWcfuF4rOoFAqsajbE94Fm+gQisqBGOksj2oXtR6QeiaPAp/icKUT9U5ihmyl3VcMt0Mi05QAVznncP2V1+mITUCJ8vo1SM8k3mB30fCHbUdkmKlRSt4SqjW80YVb8FjCCr/w== X-YMail-OSG: 2sLKH4cVM1nUjBvEQbaVQkYL3DTLGRzQOir2xPy6mDCAUtoy5eVf58lWYQlDmqi NgEmzlgSUPvb4.67PwK6KYR7FxAjaNBX0JPgqO5a8lvZ6Abkfjcs207Bma2KtNXMaa9P8ZfVacNA ZiOJAuakCjKv5DqkeQMTqBtw4zsiAA6esReft_14oImxvt0.Fwv7PW3W11q1STFWl5O2WnAVFqhM D2UabaxjgyGBNt_tYRW6Sj30PO9uBDN.hlvbPF.fPfhCbNOH3iU98Z.KFIlGAy_8mKDe914oxmSI 1oQhb8uBTzUMz7x3l._dHo8AFSntonvNz6Ne3v2tTcysl1kqiWE1iLmpCHW.S2_dPdR8KmpxZvUh Fo7StNM5Qe.OTHpdp2RRM7s3TmymlyED0Y71Q8HrMwXPVqqfYdgJ8tLE3e6gY36GcM6vOBHfh4I2 yMhfpJjHnZ3lt3IXGzaaMQ5zd4zSBtNP4Afurvv1WjxWDB97VmOdn1bpqKXpIPbv6gSJD9xVR.Fn N.wELpaFiYB9d_JOdn7w_iO3LuYmK9njHdKlhGJPyW_xr9pPOg4X2EjdQYX7CoG2qekCkC7kovPd iffCepf_4HIZaSNec9VSU4f_TcvY87_XvnU9G1huohpLiULFZQPV6AKlg5.QmdGhWJHWKo4fdR8w RuaMPzTMQ8HHjIMv9kolWAVYa8.qjz0p3YZ162uWf_8NncfjdEyFYKnNjxb1YyvTk4Th5BWqxWso BNRFTZpYooHh_GObbBD7TiduGeNZaGLm36EwwuOIZLy0o9GWuxjgQy.iP.D6knYzA5xEJyURINDt TxkICP65EXSgvZQyXWiWJZSNGNSNh0loQi8Bh76idHrEW7_.VULx2Pp.Z0k7OPXvvLmLQoH1rEsm mFvr8KxYwmlSxSZBHaaA61mEeYVc03lmOxioNsLXyZwur8MZ__sfctYkc5nWv4B8qFI6WDnCQ7JY LmmWnTxJ.jLErwEvSCQ4D2ghpPbT5.gUp57QUChIV0P9mPPltPmTARdqz9VWU_gjGGSl2v1vRHQW ZTEZPN8cNdiTdBHVxfj1olXyU9TUfakhz53oARcj4Nt90jmBEZ6F4sQZTndvu8vuGiktmSf7eTrD nyNfVCOciVm6JthbUrxE2jioGbbXs__uu7Ie5_FGtQXxxETDUu8pnmHkI99xVjizUYLBgYc4Gwkg 5.OmMBiM5IMXdplMF0TOMxuRE8WYKhZyqIsUl.75DU.aKFFOXpvmhj1pvYRMzBQOd1KytXGtVKVc TO7s8U5OsCH5FK.7_lA1vfPY3J.v5EpF4am.gqmYkDpk315J7BCn239DejirniMD4RI6dF_EzMHm hnrLO0Tcbz_hjfGawU68r888QMXtIweWg0gQV_bQT.8wNvu1MpKxj8fvzlGOGoOj23Pglql1Gq4M hR2JMHXx.wHMGZt2FmTzZyeeWOUSUjyFDHmLJ.dZ6M_rAkh7j_Pazgurd1D0y5DM5NtKX6Q5eNRO SfFEY0M2gQkiBLuRRev.j.j7nDjS9hptRVUEA3Tr9BM7N3rbloQzAGeoTW06P8RUzEo3K1yOwEkg Ai4s8H4LoAAQWh_n4KOFO2LkOFR3336suXojZUlbrilkjtwOnExr5gwYWL5PIoqyq3hBGBlMmIgW mZdbP9jPUALMMuylC2uQxwLPsKUY2tVWf5OW97dAGldEQ1_HudfchiqMReJ5GwstOiepvtLKRH64 5inJ4Jm54WLIWycVAJSWENDi2OrcW4xijuzpKTYuKDWPJ3sV45rmGlf5vfUtteVhEnjcucMFPqHu cL4Wx_ZJu_uPF2FnP2I5yKmwKV9BBSzbILkfyscXfWw0fJjHs.nX56kIPkgYF5bcOf4.Rz2ew6xi MO0JfhnKvuGUZls22X5_nz.Mt3w57DPyLk5FZw.fP76dhbJBmyH6XIaOEvm16vhAqL8wgyi1WtmF DhZozVsTFA8GGRL0bGBkzdp5w0AEK7yy2d6b3OD9ZHOxFtplHnU0_KOFGeXHD_dQoTXsLVnJrMRJ ZvB8OsXoBIe3Ao5xk5EXyJzcHPmaX5TosLCukhK0isrPJxaY3MgnkECS8vVOtJJ_mJzITLtx4kUB V5as7WgJqh32a5_oyQFcF7E41RYjXAdzyaqT7dAwLGB7VmzNpBic44TBAc3ql0nNpCDZ_MHHMx49 rubR6koMwuyQbOzckV_WAUL0_Jq9dqfHf2avdO_f_VoEPQbBzI5xJq3BzyGQ7s4AIWU3nyQDCEms cEUWuLN2YMsfbJaOtd8Ts_5o12shcowSPWytAosncWBirM7wzTXvESFENubEksphJ2Z1uUecGnDc _Pz0.SUmB_wccxNbNm10qb55..HzCM.me2tIgAXsy3nJdvykgw1ydHvncDOHCWTX0O4rHL34obVK xvG8CxTcinBvX311Hx3lMhm5wTCo87q4I7iOHwHhNfnuLFthZ9TG9VHTHDHKLzy2ighsf9muVsGH AR1wP5SCuBDpnMhTN9LUem5KNeZtgFXjCnGTQhut7PaPq6EwE5rvAz7wVBAAtA8TkmJihe.0gcnK dVnfC16i.clgkOxpTi.r2GHKRJNFidsI80Pi6l4xiapEoJR6xkzTH.FVoAy1vXzPaQDSYilv37rl laKOBZBCaCpVwv2ak X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Tue, 2 Feb 2021 21:54:25 +0000 Received: by smtp424.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a8ee1c19c7bad4675bb5cf5bd2bed207; Tue, 02 Feb 2021 21:54:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: git: 054ce2b03710 - main - atomic: add stub atomic_load_consume_ptr Message-Id: <007C2A0C-9197-4744-85BE-151873EC7203@yahoo.com> Date: Tue, 2 Feb 2021 13:54:18 -0800 Cc: "mjg@freebsd.org" To: rtc27@reebsd.org, dev-commits-src-main@freebsd.org X-Mailer: Apple Mail (2.3654.40.0.2.32) References: <007C2A0C-9197-4744-85BE-151873EC7203.ref@yahoo.com> X-Rspamd-Queue-Id: 4DVdrM3nFHz4cwD X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.65.83:from]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.65.83:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.83:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[dev-commits-src-main] X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for the main branch of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2021 21:54:28 -0000 Jessica Clarke jrtc27 at freebsd.org wrote on Mon Jan 25 23:56:41 UTC 2021 : > On 25 Jan 2021, at 22:42, Mateusz Guzik wrote: > >=20 > > The branch main has been updated by mjg: > >=20 > > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D054ce2b0371042c0dbc4b3ab1d7e7795= ad75d51e > >=20 > > commit 054ce2b0371042c0dbc4b3ab1d7e7795ad75d51e > > Author: Mateusz Guzik > > AuthorDate: 2021-01-25 20:09:41 +0000 > > Commit: Mateusz Guzik > > CommitDate: 2021-01-25 22:40:15 +0000 > >=20 > > atomic: add stub atomic_load_consume_ptr >=20 > Consume semantics is a waste of time, it's basically impossible to > implement in an optimising compiler as, in order to not emit the same > fences as an acquire, you need the source dependencies to be mapped to > data dependencies in the output assembly, but all manner of > transformations can cause that to break. And that's before you get to > hand-written atomic implementations where it is impossible for you to > ensure that, as you're not even telling the compiler what you're = doing. > For example: >=20 > int x =3D atomic_load_consume_int(p); > int y =3D q[x - x]; >=20 > This looks like stupid code, but the `x - x` cannot be constant-folded > without inserting a barrier, as currently there is data dependence at > the source level. If you use language-level atomics then it "works" by > virtue of compilers just turning consumes into acquires so the later > constant folding is safe. But if your atomic_load_consume_int is > hand-rolled magic assembly then the compiler has no clue and will > blindly go and constant fold that subtraction for you, completely > breaking your synchronisation. >=20 > Providing consume loads just doesn't make sense for FreeBSD's atomics > except for documenting the exact requirements of the code being = written; > they can never be implemented as anything other than acquire loads > unless we migrate to using actual C11 atomics, but even then you won't > get any code generation difference and likely never will. My understanding that the language standards defined the consume semantics, relative to release sequences and such, such that too much could be inferred, for example on armv8, in absence of extra code that consume was intended to avoid. For example, armv8 can do speculative consume loads across conditional branches and the dependent load can return a stale value. So the release sequence implications are being backed-off and happens-before splits into simple-happens-before (allows=20 consume to be involved) and strong-happens-before (that does not allow consume to be involved) and possibly more. This suggests to me that great care is needed in deciding to use a consume operation (not just via a specific language or language family's formal notation), probably to the point of requiring explicitly well-commenting on the guarantees in the context that allow consume to be safe and on what needs to be maintained to avoid having future changes implicit break the consume behavior. Or, may be, FreeBSD needs to more globally document just what only-minimal types inferences are to be allowed to be put to use for any FreeBSD consume use, possibly less than what the adjusted language standards are attempting. That might make such code less easy to accidentally break. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)