From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 3F3F53858404 for ; Tue, 18 Jul 2023 18:01:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F3F53858404 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-pf1-x42b.google.com with SMTP id d2e1a72fcca58-666eba6f3d6so3963140b3a.3 for ; Tue, 18 Jul 2023 11:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689703289; x=1692295289; 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=rPpNIljGQF0kIwxN64RwYJ961uBie2HAa58jIR4cKWY=; b=YZBdGwTM9FSYI49uN2ISnbhK4lO2u5i8P8dyURmYyfuoXUfkVP/odgK6PRURMICPlk X2KnGwtUUHSRCOwmXqE7Y87sjZWfRoHevzTzWpoxxTU0Y6lDq6VIUyxEpcAHBeLlDgA2 WVqDZszPZK5I6J2LyH12vSdI0B3yVyQXiCUCpO5773hP3z7ISqs709WRC6yvCFeyTDbp /vfbm54uHfylkMHHuYIUdk0F1HCau4iZnYNzv3m0XzhhgMeHAydAxHrgYJoj4Hm0Zv6r c08BQ0h3PwWFUkotCmeQVDjUMJFGlNcFydJFGPy9DhKpmh9dgaOglIiYxFumhzfa6xhJ FZoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689703289; x=1692295289; 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=rPpNIljGQF0kIwxN64RwYJ961uBie2HAa58jIR4cKWY=; b=JBPwlc/y6vzczbpK9oAnrv00m9PqvmkYcV/3v6QeqeyGUURfHhkdKZMt9mSNhFuziC dPBciXjCgZ+jzTz4ufbK1iaenA1j7Jv8ZFI8cUSvziF80T5IKrNx+OshKAFcbWpRUU4T 7X3vxyiVKOkj3MtKyAfdtMHYU0DUQme+72+riPE5qAMeJQ4aVrdiOY3vPraqkblofwfQ MH60TJ3nzo6XchgjMck3GuP5zo4mmPCNJ5VGmLxJOpAlALxO5s4B0wz+sdF4t8Pwtfiy aQ281doUxXuDyRjRpfeSGyt7FYwxadchUtoOF1pWFtQy0guWFaaS8Wp8nGxYbPYykP3/ dMyQ== X-Gm-Message-State: ABy/qLYMFTiDOEUMfe9VFdSGJ6fwo+LBLSkFByDZfAGwj9NH/ootcyiQ IM9ZCqUDrFMNx9aWeYUWehA= X-Google-Smtp-Source: APBJJlEhN1dqM2ZlSvo2OMUzoPb1gJG/aCU5bOu0UV3KlDVrtA/PWhGR6diGnPd3Xs29ZhuCUJ9mEA== X-Received: by 2002:a05:6a00:134a:b0:682:4de1:adcc with SMTP id k10-20020a056a00134a00b006824de1adccmr17085633pfu.12.1689703288809; Tue, 18 Jul 2023 11:01:28 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id h18-20020aa786d2000000b0064f51ee5b90sm1819344pfo.62.2023.07.18.11.01.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jul 2023 11:01:28 -0700 (PDT) Message-ID: Date: Tue, 18 Jul 2023 12:01:27 -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: Manolis Tsamis Cc: gcc-patches@gcc.gnu.org, Philipp Tomsich , Richard Biener , Jakub Jelinek References: <20230713141336.3950751-1-manolis.tsamis@vrull.eu> <1420ed26-9c30-b09e-f45c-54c89516814e@gmail.com> 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.3 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 7/18/23 11:15, Manolis Tsamis wrote: > On Fri, Jul 14, 2023 at 8:35 AM Jeff Law wrote: >> >> >> >> On 7/13/23 09:05, Manolis Tsamis wrote: >>> In this version I have made f-m-o able to also eliminate constant >>> moves in addition to the add constant instructions. >>> This increases the number of simplified/eliminated instructions and is >>> a good addition for RISC style ISAs where these are more common. >>> >>> This has led to pr52146.c failing in x86, which I haven't been able to >>> find a way to fix. >>> This involves directly writing to a constant address with -mx32 >>> >>> The code >>> movl $-18874240, %eax >>> movl $0, (%eax) >>> >>> is 'optimized' to >>> movl $0, %eax >>> movl $0, -18874240(%eax) >>> >>> Which is actually >>> movl $0, -18874240 >>> >>> which is wrong per the ticket. >>> The fix for the ticket involved changes to legitimate_address_p which >>> f-m-o does call but it doesn't reject due to the existence of (%eax) >>> which in turn is actually zero. >>> I believe this is not strictly an f-m-o issue since the pass calls all >>> the required functions to test whether the newly synthesized memory >>> instruction is valid. >>> >>> Any ideas on how to solve this issue is appreciated. >> I wonder if costing might be useful here. I would expect the 2nd >> sequence is the most costly of the three if address costing models are >> reasonably accurate. >> >> Another way would be to look at the length of the memory reference insn. >> If it's larger, then it's likely more costly. >> >> That's what I've got off the top of my head. >> > > I could test whether the cost function prefers the version that we > want, but that would be a workaround I would like to avoid. It may > also be the case that this reproduces with a different sequence where > the unwanted code is actually more profitable. > > I was trying to find out whether the original fix can be extended in a > way that solves this, because having an address that is reported as > legitimate but is actually not could also create issues elsewhere. > But I don't yet have a suggestion on how to fix it yet. I was thinking a bit more about this yesterday, and even in the case where the new mem crosses a boundary thus making the memory load/store more expensive I think we're still OK. The key is at worst we will have changed an earlier instruction like t = sp + into t = sp which should reduce the cost of that earlier instruction. And I would expect the vast majority of the time we completely eliminate that earlier instruction. So this may ultimately be a non-issue. Vineet @ Rivos has indicated he stumbled across an ICE with the V3 code. Hopefully he'll get a testcase for that extracted shortly. jeff