From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by sourceware.org (Postfix) with ESMTPS id 6FAAB3858D1E for ; Thu, 13 Jul 2023 14:21:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FAAB3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-579de633419so7236957b3.3 for ; Thu, 13 Jul 2023 07:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1689258061; x=1691850061; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=36MyW6N0ITXXCttkvsAEoldRao5+c2s6F3MR5QHYR7o=; b=Il482VkbQZJWm6G8TP+EmjoSvhlLuycX8PhTbYbabyQr9wSK5hv04cTwXx6DkScwKv UI3pzYEhTX2oVL75rMKyRVoxFMkC1MIRPKvShKbhSNTP1d1GWOqde81qDW8ScnAvXEqj 8r5JK5j64ypmrSM/v/wa3kvqv9Cl/x9b/KK8agJtBs0kPusefNwH9JlUly9q7zqBfErs 8KOeKNGQe1C7td4b3H8+3RjTxglNgVFMxkjF982Yj0BMuwU7w43Uc4//Z3f3QKjKvWas o0hT0c9nlLh8SMDKul0A/gC1BdDIhfyx2x3tM9edCU7W+cHRGDFjvhQpQP4kLGNOjy8R WVjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689258061; x=1691850061; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=36MyW6N0ITXXCttkvsAEoldRao5+c2s6F3MR5QHYR7o=; b=UdoeP4lbjY4xBC3v2d7cJQgfwE4nNW76l0CNe078muYhb2/RXP5pnkXh1DPr2pG8/X NU8l7IsAvHDEMMjykopyxSrOSDGCFt0POZZNfcGufc6VdQoFk585SNaC6P9eQ+/5yjkB 7xE8IslgMdygKpr2zpDgML1Y4F72Q7fLbzEJh1uRunCliI8gwPsvWAB5XD2ACr1NQrlk kXpVdU1BOxqm3PZew1pK3A/BUF51u2x4EA7rQY/4wd5rAWXiK32TDh6FQVQRM+meni7X WTpN06HYqX8zYh6pTO0ESfVd4aMUwZf48jt8Ax5z5kIipl/yY65JSrfpjeIQPNa5Y9WD Mo1A== X-Gm-Message-State: ABy/qLZp5e5o2MTEMxGBy3o8DVMMiwFjrcl+fLaXR8UKiUf7pdKyTd6r onWbRDnsD1mJgAhwF3mkqxuvMA1MSHDaPT9U3xf+OO62yrDX9g5I2VkdSw== X-Google-Smtp-Source: APBJJlHmnnPGYuxL0jFWNryZO4UkeYB+LiF6NML5fmGReOgZz27fNmPX9Jd+S6i3bNsug/ggS4g1UN9No1FJaRPlkyE= X-Received: by 2002:a81:6d4f:0:b0:573:4d89:ecb5 with SMTP id i76-20020a816d4f000000b005734d89ecb5mr1697874ywc.39.1689258061560; Thu, 13 Jul 2023 07:21:01 -0700 (PDT) MIME-Version: 1.0 References: <20230615172817.3587006-1-manolis.tsamis@vrull.eu> <52abca97-9102-5b2f-3b7b-2f55e10306b5@gmail.com> In-Reply-To: <52abca97-9102-5b2f-3b7b-2f55e10306b5@gmail.com> From: Manolis Tsamis Date: Thu, 13 Jul 2023 17:20:25 +0300 Message-ID: Subject: Re: [PATCH v2] Implement new RTL optimizations pass: fold-mem-offsets. To: Jeff Law Cc: Hans-Peter Nilsson , gcc-patches@gcc.gnu.org, Richard Biener , Philipp Tomsich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Wed, Jul 12, 2023 at 5:14=E2=80=AFPM Jeff Law wr= ote: > > > > On 7/12/23 03:12, Manolis Tsamis wrote: > > On Mon, Jul 10, 2023 at 12:58=E2=80=AFAM Hans-Peter Nilsson wrote: > >> > >> On Sun, 9 Jul 2023, Hans-Peter Nilsson wrote: > >> > >>> On Thu, 15 Jun 2023, Manolis Tsamis wrote: > >>> > >>>> This is a new RTL pass that tries to optimize memory offset calculat= ions > >>>> by moving them from add immediate instructions to the memory loads/s= tores. > >> > >>> It punts on all "use" insns that are not SET. > >>> Why not use single_set there too? > >> > >> Also, I don't see insn costs considered? > >> (Also: typo "immidiate".) > >> > > > > The only change that this pass does is to change offsets where > > possible and then simplify add immediate instructions to register > > moves. > > I don't see how this could result in worse performance and by > > extension I don't see where insn costs could be used. > > Do you have any thoughts about where to use the costs? > If the offset crosses an architectural size boundary such that the > instruction was longer, but still valid, it could affect the cost. > Ok, I haven't thought about that. I will try a prototype in case we want to include it in a next iteration of this. > That's the most obvious case to me. There may be others. > > Any progress on that m68k issue? I've also got a report of x264 failing > to build on riscv64 with the V2 variant, but I haven't distilled that > down to a testcase yet. > I have sent a V3 which contains a number of fixes and improvements: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624439.html I tested the new version rebased on master and the m68k issue did not repro= duce. I don't know what exactly fixed it; do we need to know why or is it enough that the issue is gone following some general fixes? It is highly possible that this also fixes the x264 failure. Please let me know if the issue persists with v3 once you're able to test. Manolis > jeff