From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 2BC3238582A0 for ; Thu, 13 Oct 2022 22:39:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2BC3238582A0 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-pl1-x636.google.com with SMTP id o21so696514ple.5 for ; Thu, 13 Oct 2022 15:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=AC+6Fe62ktEFosvSspgSvhNNJCj01sh1TEQEC4qQuuc=; b=nEpgZt6HuZ+Z23ddlFj/iwwHqBSvspu4iUHANxNN6vgyc1pEWd4VOCGKjm/ewEY0hU UlCZkcclwH73DuhZhQM0/RifJOJeEs+spH5XfUxzciz4fpSgzOBAnpcSoXZ7BLKUQe3M Nr4D3BsZIaVt6mljpZHxp93F8eaeGmsIA+Q+zzhplGdyqxxVs//y5fOZhwP/0wnFZXhw 9H6l2aEtQE/3ABKbt/UT1EWmoqGA05ETfOebxalL2sa6WTWgZToKjWjgjmxKB6FfIUec tbuzR0250/zmOmm8nGDDgcJhDyczVa9sWczFFI59nKSvXMMxf770se3zl02vm7lP//lB Da4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to: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=AC+6Fe62ktEFosvSspgSvhNNJCj01sh1TEQEC4qQuuc=; b=P5WJG9VO2yVlC2XCMZgjLwzfhq5gX4vLZsfUokIf8PmjJEavvjmzIzlM5kjqDJgeLa bqD09Ru42CVBHyHrxHsNznJ8JGdGVrZ1q3xJ3+sCDoHBCLbbndJjuGpt8uQvLriIjthz 1UMV3yFHx5gr4tu5OClLDLQEbuDiRWN0y7GVa9TdXoDFL6Ye/vVPLv/9Uruy0MhFDZep yBQFhYm8n1gyqseVSFwfvQEhaqgzsemjN7oEJxOpGwPfumuw490cNjtNhR/qEYLFaCUT F5B3Z+17KEwCnjdY2OWjvvQhQGULP8GI7uUjko9lY4gEz9x3REogBD6s4AJ4dr4yVLYp XvKA== X-Gm-Message-State: ACrzQf2d9u7fBcUCfOpvdOgrJcwz2amesVC0vavB/W/ps//iXAQaybkS PkhXXGYddBd2iAuLDm3sKvVp935o9XL8Mw== X-Google-Smtp-Source: AMsMyM44t5vB1PHDlrZs4KmqzuWgxuXO3YFVmkno4o74y4ZxXo5L8dJ/iSGS9NGn51Q0QBUSYzvM/w== X-Received: by 2002:a17:903:40cf:b0:17f:7d7e:95b0 with SMTP id t15-20020a17090340cf00b0017f7d7e95b0mr2123169pld.78.1665700781718; Thu, 13 Oct 2022 15:39:41 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id b20-20020a621b14000000b00560f442e4f3sm213926pfb.62.2022.10.13.15.39.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 15:39:40 -0700 (PDT) Message-ID: <47124771-dbfe-82c4-2f70-4b8c9fb19aa6@gmail.com> Date: Thu, 13 Oct 2022 16:39:39 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH v2 00/10] [RISC-V] Atomics improvements [PR100265/PR100266] Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <3862a109-8083-7a36-3d85-8f9e5e10627c@rivosinc.com> From: Jeff Law In-Reply-To: <3862a109-8083-7a36-3d85-8f9e5e10627c@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 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. But I'm also sympathetic to the desire not to break existing code.  Could we keep the old behavior under a flag and fix the default behavior here, presumably with a bit in the ELF header indicating code that wants the old behavior? Jeff