From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id E07DA3858031 for ; Thu, 15 Jun 2023 15:56:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E07DA3858031 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-x62b.google.com with SMTP id d9443c01a7336-1b51780bed0so6648275ad.3 for ; Thu, 15 Jun 2023 08:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686844597; x=1689436597; 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=9nIXkRNpN2HgmnBClpTdTca7XG2A1CY3mmvWxeaFBUs=; b=TgH8aFpUo3Qcu/JnObPUGZFp0qiaR3fTxQ3S9CLACKylyD6j2sM9haXFgRotNTaCRx 5+EU27S3e6PrNr+A4zoK+0tDYm8rEvJk84+M3asrLHTdU/NAHJhbRfdG1GXZ4ToFqKM5 C6X+wHuNr8NPmtDoafT4/RUf2csWpg8FURY+mjDDJWNQsKNfpelk/x996M5qOnd3U4OQ EiLe6Zugz3SwPQRvYMfpA/FQc1NibAvN/1+w8JS7sEIT8r2LhW5fcftjyjIy3Qy1FyhV qe2vgvVzTiAo4ys+JLvlNl7LAt6n8HUyBdf4aw+BTLq5KW34lJgpeowOcxFvFmjaNOka qZ9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686844597; x=1689436597; 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=9nIXkRNpN2HgmnBClpTdTca7XG2A1CY3mmvWxeaFBUs=; b=XzbZ2l2cxFacERE7NCUr/2vNRWZqXWmOx0jJZr+HthtarivChImHVYBrhhqsb3cftY hC/97XrOAj4ubDhxxULorW53a9ppzjm2x00ong6TI8RANUmIvvvKrnpTyPOr153uubT/ X7SLxYxgPbzs8rObocVDrD1z7zfC6uNXuGs/FRUIQlvrdU/qq2J5YNsyduMFo56DSSrK wXhnyGuJ0PhXfbD7lAIBkjSVpAO6AbK7MN6UE4/9OYvuNYWkYFcWPboQKsqa5PEA46YA uICEdAkRjUxug9h1a6GlpikOfiYuXpm2oKFi/lBdT7RFZnjZm7T7ocM6arNBW8ps5zYV OxkQ== X-Gm-Message-State: AC+VfDyhNYQOf57NjxA2N5zERcnzdbReQNBS8vOKXq5b33XIYXfbNio0 iwxivEGdCO9fRWVq8Fnc2to= X-Google-Smtp-Source: ACHHUZ6V2cyxXbn/zp24uCstIR2iEwXJ0cYWEaMukQiNaOCXgxglsvTbeN1ARUPyK8IIO4mVw0xl0w== X-Received: by 2002:a17:902:e88c:b0:1af:d812:d27 with SMTP id w12-20020a170902e88c00b001afd8120d27mr20903782plg.9.1686844596989; Thu, 15 Jun 2023 08:56:36 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id s13-20020a170902988d00b001ac937171e4sm14177543plp.254.2023.06.15.08.56.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Jun 2023 08:56:36 -0700 (PDT) Message-ID: <4f1e091a-0c3f-c7e7-eb57-50d745f0fd59@gmail.com> Date: Thu, 15 Jun 2023 09:56:35 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH 0/2] RISC-V: New pass to optimize calculation of offsets for memory operations. Content-Language: en-US To: Manolis Tsamis Cc: gcc-patches@gcc.gnu.org, Richard Biener , Palmer Dabbelt , Philipp Tomsich , Kito Cheng References: <20230525123550.1072506-1-manolis.tsamis@vrull.eu> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.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,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 6/15/23 09:30, Manolis Tsamis wrote: > On Thu, Jun 15, 2023 at 6:04 PM Jeff Law wrote: >> >> >> >> On 5/25/23 07:42, Jeff Law wrote: >> >>> Thanks Manolis. Do you happen to know if this includes the fixes I >>> passed along to Philipp a few months back? My recollection is one fixed >>> stale DF data which prevented an ICE during bootstrapping, the other >>> needed to ignore debug insns in one or two places so that the behavior >>> didn't change based on the existence of debug insns. >> So we stumbled over another relatively minor issue in this code this >> week that I'm sure you'll want to fix for a V2. >> >> Specifically fold_offset's "scale" argument needs to be a HOST_WIDE_INT >> rather than an "int". Inside the ASHIFT handling you need to change the >> type of shift_scale to a HOST_WIDE_INT as well and potentially the >> actual computation of shift_scale. >> >> The problem is if you have a compile-time constant address on rv64, it >> might be constructed with code like this: >> >> >> >> >>> (insn 282 47 283 6 (set (reg:DI 14 a4 [267]) >>> (const_int 348160 [0x55000])) "test_dbmd_pucinterruptenable_rw.c":18:31 179 {*movdi_64bit} >>> (nil)) >>> (insn 283 282 284 6 (set (reg:DI 14 a4 [267]) >>> (plus:DI (reg:DI 14 a4 [267]) >>> (const_int 1365 [0x555]))) "test_dbmd_pucinterruptenable_rw.c":18:31 5 {riscv_adddi3} >>> (expr_list:REG_EQUAL (const_int 349525 [0x55555]) >>> (nil))) >>> (insn 284 283 285 6 (set (reg:DI 13 a3 [268]) >>> (const_int 1431662592 [0x55557000])) "test_dbmd_pucinterruptenable_rw.c":18:31 179 {*movdi_64bit} >>> (nil)) >>> (insn 285 284 215 6 (set (reg:DI 13 a3 [268]) >>> (plus:DI (reg:DI 13 a3 [268]) >>> (const_int 4 [0x4]))) "test_dbmd_pucinterruptenable_rw.c":18:31 5 {riscv_adddi3} >>> (expr_list:REG_EQUAL (const_int 1431662596 [0x55557004]) >>> (nil))) >>> (insn 215 285 216 6 (set (reg:DI 14 a4 [271]) >>> (ashift:DI (reg:DI 14 a4 [267]) >>> (const_int 32 [0x20]))) "test_dbmd_pucinterruptenable_rw.c":18:31 204 {ashldi3} >>> (nil)) >>> (insn 216 215 42 6 (set (reg/f:DI 14 a4 [166]) >>> (plus:DI (reg:DI 14 a4 [271]) >>> (reg:DI 13 a3 [268]))) "test_dbmd_pucinterruptenable_rw.c":18:31 5 {riscv_adddi3} >>> (expr_list:REG_DEAD (reg:DI 13 a3 [268]) >>> (expr_list:REG_EQUIV (const_int 1501199875796996 [0x5555555557004]) >>> (nil)))) >> >> >> >> Note that 32bit ASHIFT in insn 215. If you're doing that computation in >> a 32bit integer type, then it's going to shift off the end of the type. >> > Thanks for reporting. I also noticed this while reworking the > implementation for v2 and I have fixed it among other things. > > But I'm still wondering about the type of the offset folding > calculation and whether it could overflow in a bad way: > Could there also be edge cases where HOST_WIDE_INT would be problematic as well? > Maybe unsigned HOST_WIDE_INT is more correct (due to potential overflow issues)? I think HOST_WIDE_INT is going to be OK. If we overflow a H_W_I, then there's bigger problems elsewhere. jeff