From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id AC15B3858C56 for ; Thu, 13 Oct 2022 19:31:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AC15B3858C56 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x62f.google.com with SMTP id l4so2707311plb.8 for ; Thu, 13 Oct 2022 12:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:cc:to:subject:from:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=CI7CBNxuBIPQy1WtP7ZQiuW5QjPrIzbeMkPLeeHosoc=; b=Tx7MaMsUjUcCTsd6qoKBy3b53zeFwMkDCZyjyqxfvCujZe0szWFESJlFJwbq7+6Ifl 2TxMdlZvWjKIAt6Xue0iE27YtwJdYL2pFf1LH0fe2fVc8jOmI7xmFALtwhWaeMShiE2e AD21hs1mxHi2zjnkcb6PJa19TFy6JEiYeTmj9AcLYCQ1puArlc+VjLaIr4oi4bjDq+8H XN8Lt2/M1O84mHDf9KepaigNwZuLgh0Rc8DDGCrldvMfM5nRm6EqRsVk4GCq+vfOaxaP Jt+bQxnfRhAQHQaplUDfl6H1zAvRxbnu8bu5lFeLm86cXhu/8zkrq+0oKjLP0wc84th0 0EEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:from:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=CI7CBNxuBIPQy1WtP7ZQiuW5QjPrIzbeMkPLeeHosoc=; b=FA+w3eizBCgTGLerDVu5/rpfX+bU+gxob0Vl+7RyMKXvATgvlSByDEHE769hjS8D3+ kFC+onOo48dY24Banq0sw0ir/pNGEysSdyuh2Xj7udmJcbXSTUJUg7OFXcVPwl4tREcL bykwsO8bJ8No7UM4hwxxxU1DckM74bTY9fUfxcUImInWt9/UVuUUm8InbLpP5oO/O2IB PB1z0genxbH9Q5WpG7eCo4Fr1Ld6Mm+KHhNefG9leZTJ6TEq8xCsNyeDngDxy6DnRvAf EGuCQx2RS6DRx2LMusfVByPPOlXVAcsPTeTQ7wAsXBLspI5GRHCGzgGqAhdKn+k27XzS RIfQ== X-Gm-Message-State: ACrzQf1+IQv+B3P41YRj5FluJ4Dgxnk2WSR4yJR7LitLLFabmU3O/DQK j1TyxAjbfduRqxnMch5xOpWwLQ== X-Google-Smtp-Source: AMsMyM7pUFCXZ9U6B6FRATzNa6OGqIKB8dEiJuZSA8VaCzyAXuj17qio3igmK3gdg7Px+HyqFvrgrA== X-Received: by 2002:a17:90b:1649:b0:20d:2d96:6b05 with SMTP id il9-20020a17090b164900b0020d2d966b05mr13047975pjb.9.1665689477625; Thu, 13 Oct 2022 12:31:17 -0700 (PDT) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id y20-20020a170902ed5400b001732a019dddsm212906plb.174.2022.10.13.12.31.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 12:31:17 -0700 (PDT) Message-ID: <8c7380d2-2587-78c7-a85a-a4c8afef2284@rivosinc.com> Date: Thu, 13 Oct 2022 12:31:15 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: en-US From: Vineet Gupta Subject: Fences/Barriers when mixing C++ atomics and non-atomics To: tech-unprivileged@lists.riscv.org, gcc@gcc.gnu.org Cc: Hans Boehm , Hongyu Wang , Uros Bizjak Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, I have a testcase (from real workloads) involving C++ atomics and trying to understand the codegen (gcc 12) for RVWMO and x86. It does mix atomics with non-atomics so not obvious what the behavior is intended to be hence some explicit CC of subject matter experts (apologies for that in advance). Test has a non-atomic store followed by an atomic_load(SEQ_CST). I assume that unadorned direct access defaults to safest/conservative seq_cst. extern int g; std::atomic a; int bar_noaccessor(int n, int *n2) {     *n2 = g;     return n + a; } int bar_seqcst(int n, int *n2) {     *n2 = g;     return n + a.load(std::memory_order_seq_cst); } On RV (rvwmo), with current gcc 12 we get 2 full fences around the load as prescribed by Privileged Spec, Chpater A, Table A.6 (Mappings from C/C++ to RISC-V primitives). _Z10bar_seqcstiPi: .LFB382:     .cfi_startproc     lui    a5,%hi(g)     lw    a5,%lo(g)(a5)     sw    a5,0(a1) *fence    iorw,iorw*     lui    a5,%hi(a)     lw    a5,%lo(a)(a5) *fence    iorw,iorw*     addw    a0,a5,a0     ret 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 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. Perhaps this begs the general question of intermixing non atomic accesses with atomics and if that is undefined behavior or some such. I skimmed through C++14 specification chapter Atomic Operations library but nothing's jumping out on the topic. Or is it much deeper, related to As-if rule or something. Thx, -Vineet