From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 5720A385DC2E for ; Thu, 6 May 2021 00:27:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5720A385DC2E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jimw@sifive.com Received: by mail-ej1-x62f.google.com with SMTP id m12so5639322eja.2 for ; Wed, 05 May 2021 17:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lApt0R16ezjtp/X7qmwJQ5SnSbUCTS90Q2Z9N9m5DqM=; b=XmeC9Uj4jguZTk9U3OFOxWWzl5ptTHy+fBsvkWi+11NH1eoNyhcJ43ZnOfdF9qVb2B TA+dF9QA1BG5C04tpj74z7XfJDuOKd4PYmTRHqGviRU/H8sM80C8Knm+MPAjLs11Lsck kfxfDoXDNMnEpML0bfnErKNVjvqnotHYWnLVpoMoNsgsVnnoQltHb3ZSvZqFu7gHEIdS mstCiHRl6BSsLwVb7SSATJ1HJGFqu9UQ/W+Swm3+f8U185UTi/Ltufi9mETbg/hWT3WW ZFMrW8YcR4jkWWCXJmNLRttm6JDENc7cZWo9ib7AKZNj0f5IQRuGIkaHdzd7WKAsQyUG 0VnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lApt0R16ezjtp/X7qmwJQ5SnSbUCTS90Q2Z9N9m5DqM=; b=C5XXRTuNqb250o3Uo+ueEk9+adTX/SGcEXrrrhK6Qfgn3P7/28SWNH2ATqLOtxLCEa qUMN+WvsgUfsbgjLBmhZCwnQCZs7b3yCG1b6GbnmxsmT1flPs3H19CMw8GPl2toqQhb6 /6iYMYOpsr1m6+v57Vtm73jr4z0P/Qx895p808vkY5g1xZzLSAQ4rP0dDpXhDT9qTPq8 NdpPMRHKpzRaMR8UniyhUNlMxl0ruzIr9xjHCvtRvYYD4uvh25cAl42XgETNMkOt8uXy 6nE1Dbp6L/kDXtPmI0INRPbhjzWetedrbtoMqbPbK4npayAaMbqHZpVICX7fmfgpWAS2 8pAg== X-Gm-Message-State: AOAM532Lo+HiwezmHKm7JELHrUeAXIOmTTJMXHwrq96uqy58mCvQJ16m jt2daRtU0KDoYwMRucJziZfvzhxDMkMTgMQZQRhYbw== X-Google-Smtp-Source: ABdhPJwBTxHHzpLzfXKEPZUtlsvC9yDJqI3kGViJ6dNZNh52+3SKxNn5kZyKX6p09LP338uzCcHvMUtxxl/qToB3SRc= X-Received: by 2002:a17:906:1fca:: with SMTP id e10mr1410427ejt.486.1620260850175; Wed, 05 May 2021 17:27:30 -0700 (PDT) MIME-Version: 1.0 References: <20210505193651.2075405-1-cmuellner@gcc.gnu.org> <20210505193651.2075405-10-cmuellner@gcc.gnu.org> In-Reply-To: <20210505193651.2075405-10-cmuellner@gcc.gnu.org> From: Jim Wilson Date: Wed, 5 May 2021 17:27:19 -0700 Message-ID: Subject: Re: [PATCH v2 09/10] RISC-V: Provide programmatic implementation of CAS [PR 100266] To: Christoph Muellner Cc: GCC Patches , Kito Cheng X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 00:27:33 -0000 On Wed, May 5, 2021 at 12:37 PM Christoph Muellner wrote: > The existing CAS implementation uses an INSN definition, which provides > the core LR/SC sequence. Additionally to that, there is a follow-up code, > that evaluates the results and calculates the return values. > This has two drawbacks: a) an extension to sub-word CAS implementations > is not possible (even if, then it would be unmaintainable), and b) the > implementation is hard to maintain/improve. > This patch provides a programmatic implementation of CAS, similar > like many other architectures are having one. > A comment that Andrew Waterman made to me today about the safety of this under various circumstances got me thinking, and I realized that without the special cas pattern we can get reloads in the middle of the sequence which would be bad. Experimenting a bit, I managed to prove it. This is using the old version of the patch which I already had handy, but I'm sure the new version will behave roughly the same way. Using the testsuite testcase atomic-compare-exchange-3.c as before, and adding a lot of -ffixed-X options to simulate high register pressure, with the compiler command ./xgcc -B./ -O2 -S tmp.c -ffixed-x16 -ffixed-x17 -ffixed-x18 -ffixed-x19 -ffixed-x20 -ffixed-x21 -ffixed-x22 -ffixed-x23 -ffixed-x24 -ffixed-x25 -ffixed-x26 -ffixed-x27 -ffixed-x28 -ffixed-x29 -ffixed-x30 -ffixed-x31 -ffixed-x15 -ffixed-x14 -ffixed-x13 -ffixed-x12 -ffixed-s0 -ffixed-s1 -ffixed-t2 -ffixed-t1 -ffixed-t0 I get for the first lr/sc loop .L2: lui a1,%hi(v) addi a0,a1,%lo(v) lr.w a1, 0(a0) ld a0,8(sp) sw a1,24(sp) bne a1,a0,.L39 lui a1,%hi(v) addi a0,a1,%lo(v) lw a1,16(sp) sd ra,24(sp) sc.w ra, a1, 0(a0) sext.w a1,ra ld ra,24(sp) bne a1,zero,.L2 and note all of the misc load/store instructions added by reload. I don't think this is safe or guaranteed to work. With the cas pattern, any reloads are guaranteed to be emitted before and/or after the lr/sc loop. With the separate patterns, there is no way to ensure that we won't get accidental reloads in the middle of the lr/sc loop. I think we need to keep the cas pattern. We can always put C code inside the output template of the cas pattern if that is helpful. It can do any necessary tests and then return an appropriate string for the instructions we want. Jim