From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 629343858C56 for ; Thu, 13 Oct 2022 21:14:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 629343858C56 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-pg1-x529.google.com with SMTP id r18so2591716pgr.12 for ; Thu, 13 Oct 2022 14:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=QPaW62Hn47a8PKy5rW4yyGuqgGtp1CadhvlsdBORcGA=; b=x0BwKueaJg/oZBrvZh8aYNBfqw7sKjYMkxjpWnJpS2MkdSz8+AbJWXtOsUFE8mHRTH Nz38ATLtWsW/i2eJ+WoxCadB9VuHMM2RogfTAr2ATqwxsaKgOuJtAV1iwrQyhqPRtYhx W2VTp6HkLhjKZmCcqid+ajvgrjmgA16ihZ7r8+bwkyvltEfhn1rphCy/HgNxfY6LOyRk xoB4ZS4JWGVuN5dA4J50r1oDKw2iS5VyeXXyHr1jZhfZXwUFtLbDf+n6/7b5708tuJe1 nQmxfvROD9PCZ+XY6FAjs6uBhfXZLhMzpJ7um8r4ZbkCCd1RdMrZreD819Bb25ypR9m+ lhQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=QPaW62Hn47a8PKy5rW4yyGuqgGtp1CadhvlsdBORcGA=; b=6qBWtU5ALxWKoh+baUW2pR+S3J+xdswzcwhHuF6GSF/Mbatmy9OmqprZE9hfyaaGj1 Yi8HLhx0uLzxMp/PsWLxxCy6EVry94n8PDtxpxgJwEiypiuOuJDoFRktpkPukvdvYrY6 DCzIbQpGlNXCKNfXJr/acU1yUg+DIH/M+F9lJuIseHshS1L9/1b/fU8Tx0BfEK6qsgSi GYlu6DeR6NPw0OZwfp9u/fcTE4uBEo5yxAikdhrDx4SDDCczux8HCw9lBbonyoXAN/iV F2M0yutLx/BtMOUj5c2BhIbr6I7rgo1rgQbTbF/4o434yOE9vBb0hooRt6jhg11J/iT0 sFWA== X-Gm-Message-State: ACrzQf1aKf7+fuV3N6yhsdJxiIpOgysx5vjq5M3biJf9I4C4isnAgAht i1vUePav+j/TF1rmQDlx1b+BvA== X-Google-Smtp-Source: AMsMyM6juWU/22ZtsVw3FB+wiecIc8r3fe0TKf17cdN7iQ/1VdSvVJ/B45UT4jcB4tMv9cxQMfVc+A== X-Received: by 2002:a05:6a00:1d05:b0:563:5715:7f3d with SMTP id a5-20020a056a001d0500b0056357157f3dmr1666701pfx.48.1665695685315; Thu, 13 Oct 2022 14:14:45 -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 i18-20020a056a00005200b00561b02e3118sm144557pfk.106.2022.10.13.14.14.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 14:14:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------V7huneztHTdSqGmKGBSnEgV1" Message-ID: Date: Thu, 13 Oct 2022 14:14:41 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Fences/Barriers when mixing C++ atomics and non-atomics Content-Language: en-US To: Uros Bizjak Cc: tech-unprivileged@lists.riscv.org, gcc@gcc.gnu.org, Hans Boehm , Hongyu Wang References: <8c7380d2-2587-78c7-a85a-a4c8afef2284@rivosinc.com> From: Vineet Gupta In-Reply-To: X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,NICE_REPLY_A,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: This is a multi-part message in MIME format. --------------V7huneztHTdSqGmKGBSnEgV1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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® 64 and IA-32 Architectures > Software Developer’s 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 > > • Reads are not reordered with other reads. > • Writes are not reordered with older reads. > • Writes to memory are not reordered with other writes, with the > following exceptions: > ... > • 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 different location and thus potentially could be reordered. --------------V7huneztHTdSqGmKGBSnEgV1--