From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id EC2153829BF8 for ; Tue, 18 Apr 2023 20:48:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC2153829BF8 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-pl1-x631.google.com with SMTP id z2so301278ple.0 for ; Tue, 18 Apr 2023 13:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1681850895; x=1684442895; h=content-transfer-encoding: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=cUYC7FSEjWwQfASBM6aK4VPYR85IXyvMVNJcjGeS1vk=; b=fHL6bm4R346NEURwe3sXhKSb6PR13WjzS9iIAKcrjnSFIcZlWHdkYkM5pE6Y04+OBp yE2gj2zpV7Bl8LhQHLNvlOOBtfUoTrxhA9qvaQq4RU14OXtc9QT7wUnovJZn+gQ1l/Ev sK9eG+e9tkrmoY03jnr4yXL5NMr0cj85I9lqL6L+bIlPpUor0UDZImoDWurrtLmwrtPt JlDI/4EQOwsxizlRxdCa7tc+Cnf/BYptvl7pqGl8MSjVLeYhW8Aw+5cKjU1mKVfztC1+ DfJ+rX/DIPioQ5ODB3g/gJtEH5M15yPvQKrMBPl+PW96BMSM7qYFUza/Ho7DBHoa1zfE TAkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681850895; x=1684442895; h=content-transfer-encoding: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=cUYC7FSEjWwQfASBM6aK4VPYR85IXyvMVNJcjGeS1vk=; b=b7+l7UsGXOe31KUSPeEn+a8sIJ+dH8+vi6O4H1JKX5yOi+rfoTZf2zg9KA1D0IgLHI QYKc6uXmVvCoI7qVtzggLskaAsSL/A82pYpR//az1ShjBzhM4uFrjGab+ztArJHJiWgf kyWbKNi3irqZOMfSVkUmaAwK7X5SdWAikTWyv6CswG+wbPr8ItiFyVtgZCLW8y1R0Di/ PQ7Sw6ze5OLw2SqPTQO4kiGQazCB8LWbbqEPTxEIVJs5OxHmxc601uK4tZMhaO1rB7ZP nI53E5H7m3b35pykUZ3yUyKtpLtDPW/6KTT3fDseFdxcOdH99VZqMzZZDwe+gppdWKNn KZNg== X-Gm-Message-State: AAQBX9dU313wdSjEyIIKBJyjq7M2xuGbRAoAJTNDw1tlNDK6yTyJZ6S8 GFe2C16T0ZWe/6bb0xVbaAWCBg== X-Google-Smtp-Source: AKy350Z++xI6Gq1l353SP+ovbz/FREZqOPK2P47mXPcWM+57G2Am/rxxA2GqPtgpiVdexk/vrDQHIw== X-Received: by 2002:a05:6a20:1a86:b0:f0:f2a:ff4f with SMTP id ci6-20020a056a201a8600b000f00f2aff4fmr906924pzb.8.1681850894776; Tue, 18 Apr 2023 13:48:14 -0700 (PDT) Received: from [10.0.17.156] ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id s30-20020a63215e000000b0051b5d0fe708sm8131405pgm.43.2023.04.18.13.48.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Apr 2023 13:48:14 -0700 (PDT) Message-ID: Date: Tue, 18 Apr 2023 13:48:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v5] RISCV: Inline subword atomic ops Content-Language: en-US To: Jeff Law , gcc-patches@gcc.gnu.org Cc: palmer@rivosinc.com, kito.cheng@gmail.com, david.abd@gmail.com References: <20220821215823.18207-1-palmer@rivosinc.com> <20230418142858.2424851-1-patrick@rivosinc.com> From: Patrick O'Neill In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 4/18/23 09:59, Jeff Law wrote: > On 4/18/23 08:28, Patrick O'Neill wrote: > ... >> +  rtx addr = force_reg (Pmode, XEXP (mem, 0)); >> + >> +  rtx aligned_addr = gen_reg_rtx (Pmode); >> +  emit_move_insn (aligned_addr,  gen_rtx_AND (Pmode, addr, >> +                          gen_int_mode (-4, Pmode))); > So rather than -4 as a magic number, GET_MODE_MASK would be better. > That may result in needing to rewrap this code.  I'd bring the > gen_rtx_AND down on a new line, aligned with aligned_addr. IIUC GET_MODE_MASK generates masks like 0xFF for QI (for example). It doesn't have the granularity to generate 0x3 (which we can NOT to get -4). I searched the GCC internals docs but couldn't find a function that does address alignment masks. > Presumably using SImode is intentional here rather than wanting to use > word_mode which would be SImode for rv32 and DImode for rv64?  I'm > going to work based on that assumption, but if it isn't there's more > work to do to generalize this code. It's been a year but IIRC it was just simpler to implement (and to me it didn't make sense to use 64 bits for a subword op). Is there a benefit in using 64 bit instructions when computing subwords? >> + >> +(define_expand "atomic_fetch_nand" >> +  [(set (match_operand:SHORT 0 "register_operand" "=&r") >> +    (match_operand:SHORT 1 "memory_operand" "+A")) >> +   (set (match_dup 1) >> +    (unspec_volatile:SHORT >> +      [(not:SHORT (and:SHORT (match_dup 1) >> +                 (match_operand:SHORT 2 "reg_or_0_operand" "rJ"))) >> +       (match_operand:SI 3 "const_int_operand")] ;; model >> +     UNSPEC_SYNC_OLD_OP_SUBWORD))] >> +  "TARGET_ATOMIC && TARGET_INLINE_SUBWORD_ATOMIC" > Just a note, constraints aren't necessary for a define_expand. They > don't hurt anything though.  They do document expectations, but then > you have to maintain them over time.  I'm OK leaving them, mostly > wanted to make sure you're aware they aren't strictly necessary for a > define_expand. I wasn't aware, thanks for pointing it out! - you're referring to the "TARGET_ATOMIC && TARGET_INLINE_SUBWORD_ATOMIC", (not the register constraints) right? > ... Thanks for reviewing! Patrick