From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 4F7CA3858C39; Thu, 13 Oct 2022 23:12:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F7CA3858C39 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-pj1-x102e.google.com with SMTP id a6-20020a17090abe0600b0020d7c0c6650so6317373pjs.0; Thu, 13 Oct 2022 16:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=GBobk+ZAGbWSM1jWHK919WlTvNpKFx9Y9yREOqF2gL0=; b=iuooZnAjuB1awOmQFLLMUPsnRiA/Z4Y6X6L04Bw1LoNSGxi3cJOxFX7darz4h2+V6D 9LIfj9VDqVudD7ZcShwx2VtZDZ8w4kdK/Qd4RxKBcqQS8izdBETIBQQcay8CeDj+Q8Wj 3FYQMQ/HGhjij5S3LPQLF2Mc8Q8wWLMIwR3kn6ZMNjzYdJIXp2aBHfHgEOHRpsa99+F5 OaZa6SBJRkFj3OmWn4WsABNrqtEUAYOHYZXYmnRzai/ZKfT6xbsWV4AxQgyulPrfrxmW m01zbbiHXIT/mpZrR7bV1OvkPlJvt7VNwGFXSHQsakRT4GV3jlvPA6ao4+d8+YlTgVns k/OQ== 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=GBobk+ZAGbWSM1jWHK919WlTvNpKFx9Y9yREOqF2gL0=; b=wW9A8VzEJK4eErNIIchHBYXKbJ311xVi+2M8q6vFHuuNBEo58kULyHbBVwwAtR2OSF 3f1me7/qLSAcQ3sDBgpyCo64QNg3YkMvciYz6zbNqQlwI6cCuWiNCUkGNiV1lMx2COSi cPLHtQk03KDhGzsy6qRFsnsye+GFVnMpFOebIPu7olzjwDjmVn+RoMfql+uCfE+p5Unf KYsRHmB011Ikn1YeWZg7C9fxTjkdoqfffoBy5YYPXKOGAl0n/KQ8dK2SliV8zCc8X53C 1VGb4NiaXvm+ucCTroPWA74DG8jS7+MIdny1ZI3pe4wcILyBVAMDTwKRYQJ2phoBwiaI l/gQ== X-Gm-Message-State: ACrzQf3gbpO2aMGeQHLXVbeF9JyDa/i8Je5NsK3Awd+g61+BzngpFr/O liHd+EdbKZi5OdZ731HNx+6bZy6WDkmSPw== X-Google-Smtp-Source: AMsMyM5gWEazhwAHi4ZOHHWIybdqQubY6T4d2gBY7f9/Q37RrDSaY38Q+KOeswF0NSZLMcMyphg7sw== X-Received: by 2002:a17:90b:1d0d:b0:20d:a883:5c87 with SMTP id on13-20020a17090b1d0d00b0020da8835c87mr2280375pjb.133.1665702768917; Thu, 13 Oct 2022 16:12:48 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id v8-20020a654608000000b0044046aec036sm216872pgq.81.2022.10.13.16.11.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 16:11:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------Kt2ARIHi0g0yagSIpdJ6nMg5" Message-ID: <63025f89-aa29-56b8-887d-7dbab3a5ed64@gmail.com> Date: Thu, 13 Oct 2022 17:11:16 -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: =?UTF-8?Q?Christoph_M=c3=bcllner?= , Palmer Dabbelt Cc: Vineet Gupta , Andrea Parri , gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, gnu-toolchain@rivosinc.com References: <3862a109-8083-7a36-3d85-8f9e5e10627c@rivosinc.com> From: Jeff Law In-Reply-To: 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,HTML_MESSAGE,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: This is a multi-part message in MIME format. --------------Kt2ARIHi0g0yagSIpdJ6nMg5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/12/22 02:03, Christoph Müllner wrote: > > > So we have the following atomics ABIs: >  I) GCC implementation >  II) LLVM implementation >  III) Specified ABI in the "Code Porting and Mapping Guidelines" > appendix of the RISC-V specification And presumably we don't have any way to distinguish between I and II at the DSO or object level.  That implies that if we're going to get to III, then we have to mark new code.  We obviously can't mark pre-existing bits (and I may have implied we should do that in my earlier message, my goof). > > And there are two proposed solutions: >  a) Finding a new ABI that is compatible with I) and II) is of course > a solution, but we don't know if and when such a solution exists. >  b) Going to introduce III) causes a break and therefore needs special > care (e.g. let the user decide via command line flag or provide a > compatibility mode). > > I don't see that a) and b) contradict each other. > Why not going for both: >  -) Continue to work on a backward compatible solution >  -) Enable the "new" ABI from the specification appendix via command > line flag >  -) Reevaluate the situation in 12 months to decide the next steps I would lean towards making the new, more correct, behavior the default and having the old behavior enabled by a command line flag. But otherwise what you're suggesting seems reasonable. Jeff --------------Kt2ARIHi0g0yagSIpdJ6nMg5--