From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) by sourceware.org (Postfix) with ESMTPS id B1F303858C55 for ; Thu, 13 Oct 2022 21:29:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B1F303858C55 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-35ceeae764dso29646597b3.4 for ; Thu, 13 Oct 2022 14:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Y+L3EFVXPetmobcdkcQa8OVXQQTQ5O97Mqfm/7VrLok=; b=LGUNb3YZODxzzYdEnqv09GhLHQNxhWKjmlYEv0YsnHEUIJyGSpsCsVgOD2tyr79vX6 k5dzaOes0/WesrkuEuu8oXnIPzXdWz1pbR+4DBPGmKWBSCJ00b9A8AmflQPmN1Tykkon XVJ6lAGo/vgoI84OFfVolxcskMMbMXweV3SdfqwFoZ3nyfUQR/YidjEGxKuLxhMBm/YW Dgna2E5p3VGGJQzf39SGm3ceqRoQkyMAEQgEOH4HxgXhLSZHJtwvfSseddR28dcKqUzr EGcTekGRV+nqWP1tp2M52anilP4TjuAdKRMTvu+n8Zqp1JpER91YMA/PgG2HMADPUteD 9rfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=Y+L3EFVXPetmobcdkcQa8OVXQQTQ5O97Mqfm/7VrLok=; b=M+in3jstRUcez0jtkTK2VkTIjjZJ9PnZkOFa5IeEV2ExgJ8N3vx++ytizsOI5Q4L3L hAagzZLU5xGJmpheMACUx3mnuu2UjfSlM/wJlB3jP9XuZhMjjQv9q26TaH8hLLT4Rofd FKQbYdMvn1pqlBeQUTuS9pu26P3Di1SkEuCAOZyNnJESFxj7NeujfJoj9ahObdvAtmex Mfb1BjLvFj5sq1xD6BKM1c3Hn8lDdPIYqLrvgAWiKL+wFuP7NimLOm+g++O7A/z3Qa0J spI/qWaR70bp2LcQjMDDnYyUDNGBqwlhVYm+AtAbFmzinAe5vDWl167rfoBXJX7zwD03 l7sw== X-Gm-Message-State: ACrzQf18QN1AT4jc2sSk9QfdmMLnZKQGjyvuOnz+qTG+gQi2/TudsFBN quuj3vOLB63Gb3VLzk33FX4rCIJSLQhS0qYhYQs= X-Google-Smtp-Source: AMsMyM74iinUF23rdGgVrQCE9mfRnZVPjHrlqKBj3L3bHomw0dtTG4mdrk6XKzwPgIE7tY9+uEisSZJ4RDRE56zJZbg= X-Received: by 2002:a81:148f:0:b0:357:a69d:bb5f with SMTP id 137-20020a81148f000000b00357a69dbb5fmr1834083ywu.495.1665696559021; Thu, 13 Oct 2022 14:29:19 -0700 (PDT) MIME-Version: 1.0 References: <8c7380d2-2587-78c7-a85a-a4c8afef2284@rivosinc.com> In-Reply-To: From: Uros Bizjak Date: Thu, 13 Oct 2022 23:29:08 +0200 Message-ID: Subject: Re: Fences/Barriers when mixing C++ atomics and non-atomics To: Vineet Gupta Cc: tech-unprivileged@lists.riscv.org, gcc@gcc.gnu.org, Hans Boehm , Hongyu Wang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Oct 13, 2022 at 11:14 PM Vineet Gupta wrote: > > > > On 10/13/22 13:30, Uros Bizjak wrote: > > OTOH, for x86 (same default toggles) there's no barriers at all. > > _Z10bar_seqcstiPi: > endbr64 > movl g(%rip), %eax > movl %eax, (%rsi) > movl a(%rip), %eax > addl %edi, %eax > ret > > Regarding x86 memory model, please see Intel=C2=AE 64 and IA-32 Architect= ures > Software Developer=E2=80=99s Manual, Volume 3A, section 8.2 [1] > > [1] https://www.intel.com/content/www/us/en/developer/articles/technical/= intel-sdm.html > > My naive intuition was x86 TSO would require a fence before > load(seq_cst) for a prior store, even if that store was non atomic, so > ensure load didn't bubble up ahead of store. > > As documented in the SDM above, the x86 memory model guarantees that > > =E2=80=A2 Reads are not reordered with other reads. > =E2=80=A2 Writes are not reordered with older reads. > =E2=80=A2 Writes to memory are not reordered with other writes, with the > following exceptions: > ... > =E2=80=A2 Reads may be reordered with older writes to different locations= but > not with older writes to the same location. > > > So my example is the last case where older write is followed by read to d= ifferent location and thus potentially could be reordered. Yes, but can this reordening be observed under the above conditions? There is additional rule, where: In the case of I/O operations, both reads and writes always appear in programmed order. Uros.