From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 2DEB23858C2B for ; Thu, 20 Jul 2023 06:18:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DEB23858C2B 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-pf1-x431.google.com with SMTP id d2e1a72fcca58-6686708c986so367300b3a.0 for ; Wed, 19 Jul 2023 23:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1689833887; x=1690438687; 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=JZkxrJza0ZzoLQdVIZORGEl0J6chfBfJQevwsd4yHyY=; b=pMPsEryEZD4Krrl7sBOfLRUN0KecuFcvIXU6dwENxntheT57rIrw19Z2ZD5B6nti9R alfOlrtfCLdWF4EtkdrckXfU8Q7v73kFkjQPT4l2t9MAYdHVieppvB5wnZKD0NgsHZRJ xF53wszgcIu9PWRhqrsJuJCMSP5G1jAP6EPsSVlsRo1nWcZ3FaAeltOOgSeRFUCYOkRe 0koUFNsGVtYHReaRVeBYMJTEvNJtNy8/IZvclPcYSTIioVT4mn9X42lh60czxIR+cdKD BjC8nWMwrc2gVvTXYkkywhDRPrGuEKDF5i2wxxmUvx8+9+Z01yC97rQovKHk065E1M1A cUng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689833887; x=1690438687; 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=JZkxrJza0ZzoLQdVIZORGEl0J6chfBfJQevwsd4yHyY=; b=d9tQmqPqtDnBHzdULyvU6U1tdgcixacom170GyRbOM6Li3L6iBry4KuvljWx8pihCx yBquhOUXKucZOAT5wqJbq2tDjMYT8GaQVfY0F1d2ZbdkmhO+kOpD6YUEu7GauWYcErpn iE76cqSWSkYb0f/BeMfPMOEE3ub4I30ikXnIk3sFPQ2TWLmNO+nV7NRcr4QUDgtmWbA5 cb6XiGaktbjglk0e9I40iq+TgCZSFlwZA1fu4wkOZDnp5i7oHKslWVUqs78eOYikUDVO RY7jqcM5vd1bmhCCGxzCZ6VQ+ecSAP+QcjC5HHag0Q/Y178/3exTsl7nx0MvogBgTQ0Z 1JMQ== X-Gm-Message-State: ABy/qLY9PV4gPaIv00X59NDf5+ybDZhGL5qWvRpjG25ooDjFfJ9ouQGx AdSu8gMW51tKmFX2FLKQjBoJaw== X-Google-Smtp-Source: APBJJlEvkhq2cPUtpdE44MOVsazhlrqh0Yf30oaQYcq9a3LZbT5ZbfyZb01+gP/4DvjSzH8l7/O7FQ== X-Received: by 2002:a05:6a20:54a7:b0:131:a21:9f96 with SMTP id i39-20020a056a2054a700b001310a219f96mr1961382pzk.6.1689833887663; Wed, 19 Jul 2023 23:18:07 -0700 (PDT) Received: from [192.168.50.117] (c-98-210-197-24.hsd1.ca.comcast.net. [98.210.197.24]) by smtp.gmail.com with ESMTPSA id s16-20020a170902989000b001b9be3b94e5sm315328plp.303.2023.07.19.23.18.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jul 2023 23:18:07 -0700 (PDT) Message-ID: <33394d74-60c6-dd0e-55a0-0e0901f05e2e@rivosinc.com> Date: Wed, 19 Jul 2023 23:18:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets. Content-Language: en-US To: Jeff Law , 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> From: Vineet Gupta In-Reply-To: <93fd5732-145a-94ab-5a9e-5a2eb8bac886@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,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/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. > > 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 -Vineet