From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id ADC713858C56 for ; Fri, 14 Oct 2022 00:14:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADC713858C56 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-pf1-x435.google.com with SMTP id m6so3449940pfb.0 for ; Thu, 13 Oct 2022 17:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:cc:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rpKcE1p3V+WOf/ubfqubZYLl+CnUkZ6oB02r8xoeX9c=; b=DFV7KWkR+DhRhL0rZuO//ZgO6il8OHq4/43ZkwuabIVOeRMPHNf3CjUm0iyte4K9C0 1ro8tPAM7qvvarcLMr1uMLVuUQFWL91EPj0unHoPHHHaQ7u09Qq4h3zJTiI5cxV8+2YT rzYsnmc30CaXRfP1CtMN9IceKccHn/7Cs9DzvViBdTOmkmRE0SCDsC/EzKznyoDluqRP MuSXS9X2J7rlOzQJWLtnGV4zJkuSB5NDRR8HFblMcobM0sgZanEEc7Xdn3dDO27mIdHa q83eaIp0sDMh7obDUfcEY7HWogKjpiP4iNKrIi7Juv5wgYshTKsRrVmvbqZAzWDm5P5h acBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:cc:from:references: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=rpKcE1p3V+WOf/ubfqubZYLl+CnUkZ6oB02r8xoeX9c=; b=uPvAHF8jWcCR4x3ZeXva8k7+JQ6WW20G0ml8VL+838GuMVfE/3dz7jtmxYVia4WT8E QBKFLRgjsuV11/niEGdlsKPq0Qbg7H3Klu2Xh05az9CCxHZg3PpuzXBVxF8V+dH/y8Yj 1cD/7GPsu2ct7wp2NanOlYJMR1Ot1an98UtJfTCPwOxr9gUe7TXkuNZDTGN/lP2oGOHY kXYdkkR8JwglhA5TphRET0tdBxdtqBsIPTgmCT/1JIyH5GVvqPiYSFbl/UJzL49KVYNV xH4UC/094pelH9z6abK0J7eALlX8yrLfPgH9hPS6dJgivNQq1bo1lnVYYlGrLs5UeAc0 XCCw== X-Gm-Message-State: ACrzQf06ANF9ITglmRQ7wQOxww22VgkxVUNye51t63WBbPRGd5TVlPrz Ch1tRSnKTEwg3pHMeWY5owztkg== X-Google-Smtp-Source: AMsMyM5ZAA9EU/cuG5lEjnQKco66CZPqtf1rSz9wbJKRD/OcELtpSg6dIGRKdPUH1tN4d9KW1al5IQ== X-Received: by 2002:a05:6a00:4214:b0:562:67d0:77e7 with SMTP id cd20-20020a056a00421400b0056267d077e7mr2277649pfb.62.1665706474689; Thu, 13 Oct 2022 17:14:34 -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 x89-20020a17090a6c6200b0020d43c5c9a0sm318511pjj.18.2022.10.13.17.14.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 17:14:34 -0700 (PDT) Message-ID: <975b8092-6bf2-f58d-147c-318e80c70b61@rivosinc.com> Date: Thu, 13 Oct 2022 17:14:32 -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: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] Content-Language: en-US To: Jeff Law , gcc-patches@gcc.gnu.org References: <3862a109-8083-7a36-3d85-8f9e5e10627c@rivosinc.com> <47124771-dbfe-82c4-2f70-4b8c9fb19aa6@gmail.com> From: Vineet Gupta Cc: Palmer Dabbelt , Christoph Muellner In-Reply-To: <47124771-dbfe-82c4-2f70-4b8c9fb19aa6@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_SHORT,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: On 10/13/22 15:39, Jeff Law via Gcc-patches wrote: > > On 10/11/22 17:31, Vineet Gupta wrote: >> >>> >>> I expect that the pressure for a proper fix upstream (instead of a >>> backward compatible compromise) will increase over time (once people >>> start building big iron based on RISC-V and start hunting performance >>> bottlenecks in multithreaded workloads to be competitive). >>> What could be done to get some relief is to enable the new atomics >>> ABI by a command line switch and promote its use. And at one point in >>> the future (if there are enough fixes to justify a break) the new ABI >>> can be enabled by default with a new flag to enable the old ABI. >> >> Indeed we are stuck with inefficiencies with status quo. The new abi >> option sounds like a reasonable plan going fwd. >> >> Also my understand is that while the considerations are ABI centric, >> the option to faciliate this need not be tied to canonical -mabi=lp32, >> lp64d etc. It might just be a toggle as -matomic=legacy,2019 etc (this >> is not suggestive just indicative). Otherwise there's another level of >> blowup in multilib testing etc. > > If I understand the history here, we're essentially catering to code > that is potentially relying on behavior that was never really > guaranteed.   That's not really ABI -- it's more depending on specifics > of an implementation or undefined/underdefined behavior.    Holding back > progress for that case seems short-sighted, particularly given how early > I hope we are in the RISC-V journey. Exactly. I keep hearing about the potential ABI breakage but no real discussion (publicly at least) which describe in detail what exactly that ABI / old-behavior breakage is with this patch series [1]. So perhaps we can start with reviewing the patches, calling out exactly what change causes the divergence and if that is acceptable or not. And while at it, perhaps also make updates to [2] [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595712.html [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100265