From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by sourceware.org (Postfix) with ESMTPS id 2C30C3858C2B for ; Thu, 20 Jul 2023 21:59:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C30C3858C2B 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-io1-xd2e.google.com with SMTP id ca18e2360f4ac-77a62a84855so59400639f.1 for ; Thu, 20 Jul 2023 14:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689890396; x=1690495196; 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=aUFrIwOvcvp/H2Y+MIxGz5faOoSAU5t81HTj8+IQmpY=; b=InGvTIyDO0t6XKWgDIOc+T66obRG8MfMD1KJjEKVxQ5xviu42LoE+Kc+DcIlBzuUnD epiwLG7wwxjHGWcl0MHuux0xJhNXXuDe3/2sM9GLZmznx+z4CPvNlk4Tzqj1Dq7+rZ7X Mu0O9das9OioqDdpuzi+N1rwYrCUgmBMb2t3ov3dWccmuauN0Ogazw79C6TroDW8LIR6 yVS+us1FYbS68xeXZOOem3lPOSDU0JQELRKSrfZOKilVoLUkxzMW45zUZPCuy7VfFrXd lEV3dw92Y63793wgUsTP0WOWgO4EGmn4d1XlFnZtvhqW3rb6SSdsKWea2m+yejUuEPuf rVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689890396; x=1690495196; 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=aUFrIwOvcvp/H2Y+MIxGz5faOoSAU5t81HTj8+IQmpY=; b=PGiY0YybLtKC6KqKRfSThaEaBTijhmdi277Wt9OXzhFv1KFwo20SFyT6+husse54np 4rXjUBZJoulYJkTDG75EyKnCtw1sBFqb+LYKdi46NE37/f2g2z+us/7ma+FXVdSuEge+ CUyS6TUSuAj4hRkzNb2hc4TTMZvCMZF0oMBuG8T1kyOCjwPzBX4Z24h3V0cCJlNfXAw7 Sr9sQakGIv4sAAilALLtEcUWsE6XxTkNglmCGi7yT+ETHPDhVgbjXivh/p8RSVRYPzF3 LxNIXOf/rqHVqyxqZUu3vr5Ru7CtpofvjhQlZBn0+z3Sc4Lp9vm7qJ/weErbIQZUM5BL 8blg== X-Gm-Message-State: ABy/qLZ/L5pyRucCIj0JQ5RPCFnP1HkCzFQhjSHZvoCLF0N+7vVMrtKS F9rzvzWcxS2vGDKGiaZCCuo= X-Google-Smtp-Source: APBJJlEyGkQeZhtl6B905VTz9VDXa6E+Ag4061vzy+QlQVLd8midptqPHOAbbQhB1T+PO2U1aB96Pg== X-Received: by 2002:a05:6e02:1aa5:b0:347:7603:6865 with SMTP id l5-20020a056e021aa500b0034776036865mr267309ilv.11.1689890396035; Thu, 20 Jul 2023 14:59:56 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id in23-20020a17090b439700b00262eccfa29fsm3051793pjb.33.2023.07.20.14.59.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Jul 2023 14:59:55 -0700 (PDT) Message-ID: <43afd736-4980-2d14-67a2-4425acf6d523@gmail.com> Date: Thu, 20 Jul 2023 15:59:54 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets. Content-Language: en-US To: Vineet Gupta , Manolis Tsamis Cc: gcc-patches@gcc.gnu.org, Philipp Tomsich , Richard Biener , Jakub Jelinek , gnu-toolchain References: <20230713141336.3950751-1-manolis.tsamis@vrull.eu> <1420ed26-9c30-b09e-f45c-54c89516814e@gmail.com> <59f02830-eae9-6a52-dd63-48a7217905ef@rivosinc.com> <93fd5732-145a-94ab-5a9e-5a2eb8bac886@gmail.com> <33394d74-60c6-dd0e-55a0-0e0901f05e2e@rivosinc.com> From: Jeff Law In-Reply-To: <33394d74-60c6-dd0e-55a0-0e0901f05e2e@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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 7/20/23 00:18, Vineet Gupta wrote: > > > On 7/18/23 21:31, Jeff Law via Gcc-patches wrote: >>> >>> In a run with -fno-fold-mem-offsets, the same insn 93 is successfully >>> grok'ed by cprop_hardreg, >>> >>> | (insn 93 337 522 11 (set (mem/c:DF (plus:DI (reg/f:DI 2 sp) >>> |                (const_int 8 [0x8])) [4 %sfp+-8 S8 A64]) >>> |        (const_double:DF 0.0 [0x0.0p+0])) "sff.i":23:11 190 >>> {*movdf_hardfloat_rv64} >>> ^^^^^^^^^^^^^^^ >>> |     (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0]) >>> |        (nil))) >>> >>> P.S. I wonder if it is a good idea in general to call recog() post >>> reload since the insn could be changed sufficiently to no longer >>> match the md patterns. Of course I don't know the answer. >> If this ever causes a problem, it's a backend bug.  It's that simple. >> >> Conceptually it should always be safe to set INSN_CODE to -1 for any >> insn. > > Sure the -1 should be handled, but are you implying that f-mo- will > always generate a valid combination and recog() failing is simply a bug > in backend and/or f-m-o. If not, the -1 setting can potentially trigger > an ICE in future. A recog failure after setting INSN_CODE to -1 would always be an indicator of a target bug at the point where f-m-o runs. In that would be generally true as well. There are some very obscure exceptions and those exceptions are for narrow periods of time. > >> >> Odds are for this specific case in the RV backend, we just need a >> constraint to store 0.0 into a memory location.  That can actually be >> implemented as a store from x0 since 0.0 has the bit pattern 0x0. This >> is probably a good thing to expose anyway as an optimization and can >> move forward independently of the f-m-o patch. > > I call dibs on this :-) Seems like an interesting little side project. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748 It's yours :-) jeff