From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 7896A3858D28 for ; Mon, 7 Aug 2023 17:13:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7896A3858D28 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-x62d.google.com with SMTP id d9443c01a7336-1bc6bfc4b58so7488025ad.1 for ; Mon, 07 Aug 2023 10:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691428391; x=1692033191; 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=VM8A8ZXq2nY/9UUNeSByvemK2+lcFvck6++MDP7HMSY=; b=AFiij8/c54EBFOeWMeibTa13RPOxgTFZDzkR+EHc0JMlN+iIg8Ff5sl4LneSgkOcJO Lkw1MNpIfZXupFgxAMSwbpU8SmtQwFQlvjrLt8jVIfYKy5i/d0bTRofnN4K/y4YC9TH4 ymkJwV/oLG6aiiLAmgE2gqJfMmv2/+OwCeUNRCwkBjQxhpSzko7f5hPUGwLyTGK2dkrz gMrMjSbdoTHbtbvb6aAAh/miiobcG0NAdTMSBhDvY5qOQhRtlNWdgcudvGTB9ic1JWXe WpiCqcZtR+xUebX/VCGk4L6Axqks3qnp/2Vw4uueQHG+teQAhxiZ//naURKD30n+1KCd PxJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691428391; x=1692033191; 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=VM8A8ZXq2nY/9UUNeSByvemK2+lcFvck6++MDP7HMSY=; b=B9WuTqZ3CXe6bCmQjexdathwQr30qX7snfnrFtGh9AA3CWGvCL/QpA7imS5LjtKko6 LZdIcjUawWiRXT3D+2dVMs7j4Asz6e1DzNGhDhcudeJWbkDRt7Cfy99tTfTJkGK/n2so fFiSOdOTEfE0DC2JJjznDWVDupPHWlOgGXJ7BgBsYezsW1bb49sDe+fZGC4dJAWE6lKj y+PfkDBk9Gjbkri8X7/fAJr+2KADU97OimUuQBPFR2EYclBGDkdVpDLU+gijGSgzDYNx 19RDYBpMfppgCIs1A+uNyFNu83ZNRrfflbbNCbKFFlG/haPjfqya7vtSjIC6/ecwQG0N oEYg== X-Gm-Message-State: AOJu0YyV5ytNpyB+kn8lgERD8UxvqH4hr8t8vK9Ou/6xVrhAnoJYdlZz fyLXBEpU205i26OH0hIQkgk= X-Google-Smtp-Source: AGHT+IGBhT8TLeKzxLiF2B8YOSFtjG1ULJSmi8CKtrs+6Ffkm6zOt7NU907L3qXB9Ab/nq+bTJfBDA== X-Received: by 2002:a17:902:ac97:b0:1bb:de7f:a4d4 with SMTP id h23-20020a170902ac9700b001bbde7fa4d4mr7528383plr.61.1691428391241; Mon, 07 Aug 2023 10:13:11 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id iw3-20020a170903044300b001b857352285sm7155650plb.247.2023.08.07.10.13.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Aug 2023 10:13:10 -0700 (PDT) Message-ID: <5389a634-6935-97a1-45d2-f106f867e878@gmail.com> Date: Mon, 7 Aug 2023 11:13:09 -0600 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: Manolis Tsamis Cc: Vineet Gupta , 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> <43afd736-4980-2d14-67a2-4425acf6d523@gmail.com> From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,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 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 8/7/23 08:44, Manolis Tsamis wrote: > I have sent out a new v4 of this > (https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626502.html). > > In the new version I both restore the INSN_CODE as mentioned here and > I also call recog when I commit the offset change (because there may > be a change from no offset to some offsets). > I have also removed the driver function as per Vineet's suggestion. > > Last thing I have fixed a nasty bug with REG_EQUIV's that resulted in > failing bootstrap on AArch64. > > The offending sequence looked like this (in 'simplified RTX'): > > (set (reg/f:DI 3 x3) > (plus:DI (reg/f:DI 2 x2) > (const_int 8 [0x8]))) > (set (reg/f:DI 19 x19) > (plus:DI (reg/f:DI 3 x3) > (reg:DI 19 x19))) > ... > (set (reg:TI 2 x2) > (mem:TI (reg/f:DI 0 x0))) > (expr_list:REG_DEAD (reg/f:DI 0 x0) > (expr_list:REG_EQUIV (mem:TI (reg/f:DI 19 x19)) > (nil))) > (set (mem:TI (reg/f:DI 19 x19)) > (reg:TI 2 x2)) > (expr_list:REG_DEAD (reg/f:DI 19 x19) > (expr_list:REG_DEAD (reg:TI 2 x2) > (nil))) > > Were the first instruction (x3 = x2 + 8) was folded in the address > calculation of the last one, resulting in (mem:TI (plus:DI (reg/f:DI > 19 x19) (const_int 8 [0x8])), but then the previous REG_EQUIV was > incorrect due to the modified runtime value of x19. > For now I opted to treat REG_EQ/EQUIV notes as uses that we cannot > handle, so if any of them are involved we don't fold offsets. Although > it would may be possible to improve this in the future, I think it's > fine for now and the reduction of folded insns is a small %. > I have tested v4 with a number of benchmarks and large projects on > x64, aarch64 and riscv64 without observing any issues. The x86 > testsuite issue still exists as I don't have a satisfactory solution > to it yet. > > Any feedback for the changes is appreciated! Thanks for the explanation. You could just remove the REG_EQUIV note. It's not used much after allocation & reloading. Or just ignoring those insns as you've done seems reasonable as well. I doubt one approach is clear better than the other. jeff