From owner-dev-commits-src-main@freebsd.org Mon Jan 25 23:56:41 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 080934F6E43 for ; Mon, 25 Jan 2021 23:56:41 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DPmx46RdRz3shv for ; Mon, 25 Jan 2021 23:56:40 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: by mail-wr1-f54.google.com with SMTP id v15so14686766wrx.4 for ; Mon, 25 Jan 2021 15:56:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M3ccVsV+TNwJD6X6QEo37EI1ysum4HezmNgQqKM9QDg=; b=Kb96g4glmi28Sl/ZkxghnGIVn0lDLCwatr4PQLJsB/joHrehS/eE7748gOhRq8wVdc 3hGW8LGNWmRizEVlH34qZXV5NREoUDlDvAJgOufrrBw7vEZaQVAoA/WrSMMWHfj9AWEF Equm6p3lFy5o7lShkDAjR1X7k+TuEYdUaEIUMUjFQrBddBLKAbM+BWf1gFAtjk7uE412 oiXuz98Fk5fm+wFxPVqqLhMGSPMEKsZXT8FSKnlY3iVqSNQtkmfER5TU+SUaxoSC9Hbm WX5S4pEvcf9dG0CoIEtVyBWvMAmkbJOkGMlnIrqrRkeddoTKZvjsU3I4Xp7PG1mYimrA tZZQ== X-Gm-Message-State: AOAM532O/E20rHE0v4I+0G9002AwDAEHLvSiNjC0kokMdPOWg1gyv+L/ M0UkGjVrE2EoDRB2GODVMpKVOIDmegXYOKhG X-Google-Smtp-Source: ABdhPJxhWQ9Oi/Ny7VchO1bLekajwVXyYeXYP8nLS1f+I234lT1rHxCzpkCUYXzOzYvXTirl/i2JIQ== X-Received: by 2002:adf:9cc4:: with SMTP id h4mr2181776wre.403.1611618999573; Mon, 25 Jan 2021 15:56:39 -0800 (PST) Received: from [192.168.149.251] (trinity-students-nat.trin.cam.ac.uk. [131.111.193.104]) by smtp.gmail.com with ESMTPSA id e12sm9584190wrs.67.2021.01.25.15.56.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jan 2021 15:56:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: git: 054ce2b03710 - main - atomic: add stub atomic_load_consume_ptr From: Jessica Clarke In-Reply-To: <202101252242.10PMgaWJ026291@gitrepo.freebsd.org> Date: Mon, 25 Jan 2021 23:56:37 +0000 Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <18A79D6D-BCBE-4B6B-88F0-47931508C476@freebsd.org> References: <202101252242.10PMgaWJ026291@gitrepo.freebsd.org> To: Mateusz Guzik X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4DPmx46RdRz3shv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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: Mon, 25 Jan 2021 23:56:41 -0000 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 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: int x =3D atomic_load_consume_int(p); int y =3D q[x - x]; 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. 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. Jess