From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by sourceware.org (Postfix) with ESMTPS id 5943B3858D20 for ; Wed, 31 May 2023 12:19:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5943B3858D20 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-ot1-x329.google.com with SMTP id 46e09a7af769-6af7e368bb7so2465093a34.1 for ; Wed, 31 May 2023 05:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1685535581; x=1688127581; 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=D1xXojwxhicDtH6SadNFhfwe0tssh1cLILvG0zyzf2M=; b=dWAhd2EwIehavyperMXI/WCWrK3D3qnMVZ0xZJ8Ix+Exr/rxBeFLV6ezEzs8u6Rbw3 EMnXF03GKCgKt5ZfLpu+FOPHUg8KNiysoPcoeHMyhErLmWzyHlhoHyqUReMi4W9opLCw UIyxTE8nM2cUbDMzA1U98Avi9RNrZVjhi+e3LT2fX1ZrdPv4YqHZXa9vBpQxCYLSiF4Y gFiL2FYhpoazxdpkPUUMmxf0Mg6azNOrM7OjLknAIND1ypiw2C7s6fp26CIhcb4wJ9Pd BWxuj78km1i1X8QntbW11feN7koAoAcFHwCxRWIm3ElZuDwL9tCtXmBYF/Z33ckJpuLr CehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685535581; x=1688127581; 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=D1xXojwxhicDtH6SadNFhfwe0tssh1cLILvG0zyzf2M=; b=by0Kof9DbqrLhhT6kffKs+HGz9NBB3AODhFs81BvSc80HK4nJKfROkvPHqrrTf6qWs cjlDMJi3CulS+kXWqybXLK8/1aBUWyf/0ooAgC2Ck3YKHpK7Gy/B5fpXJSjmwHtoEGH1 JF6L4V2O+wsbzFtz4wqOQwXF7Fr1JfUmL3WVvfz1uOhrKSDzj0mS3PAehbQ7dsGnEc04 CANV3s7+gTjYf7/BJLdm7t/wQAiy53Wu3FiiiMgpbOPnUd4JDJaRv91RsUTiG50Yy5Fh PrC+TevmYRYoyYczUiRkcBf6xmcuebR0g8bSx7Wu7NFSpw5OhHYU1iLXgPirgrFn/4lV A4Cw== X-Gm-Message-State: AC+VfDyazaOx2NopjI1bN+ejrMNjnWP0TLElNmpSG1D8pLZmETOV0QHz DFqEtfVCnJ1bYmZ18YheHiArvVo8YvS5GA4SKPc/Qw== X-Google-Smtp-Source: ACHHUZ6jfi1hZrMPW0GC8QtbcKsegGlNlF8v0NwkG/c4HFSupy/YcoHdcRUiTZtT72/nmFNgou87G96r40PthHjkxok= X-Received: by 2002:a05:6358:590f:b0:121:4cd3:7d01 with SMTP id g15-20020a056358590f00b001214cd37d01mr496887rwf.29.1685535581614; Wed, 31 May 2023 05:19:41 -0700 (PDT) MIME-Version: 1.0 References: <20230525123550.1072506-1-manolis.tsamis@vrull.eu> <20230525123550.1072506-2-manolis.tsamis@vrull.eu> In-Reply-To: From: Manolis Tsamis Date: Wed, 31 May 2023 15:19:05 +0300 Message-ID: Subject: Re: [PATCH 1/2] Implementation of new RISCV optimizations pass: fold-mem-offsets. To: Jeff Law Cc: Richard Biener , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,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 Tue, May 30, 2023 at 2:30=E2=80=AFAM Jeff Law wr= ote: > > > > On 5/25/23 08:02, Manolis Tsamis wrote: > > On Thu, May 25, 2023 at 4:53=E2=80=AFPM Richard Biener via Gcc-patches > > wrote: > >> > >> On Thu, May 25, 2023 at 3:32=E2=80=AFPM Jeff Law via Gcc-patches > >> wrote: > >>> > >>> > >>> > >>> On 5/25/23 07:01, Richard Biener via Gcc-patches wrote: > >>>> On Thu, May 25, 2023 at 2:36=E2=80=AFPM Manolis Tsamis wrote: > >>>>> > >>>>> Implementation of the new RISC-V optimization pass for memory offse= t > >>>>> calculations, documentation and testcases. > >>>> > >>>> Why do fwprop or combine not what you want to do? > >>> I think a lot of them end up coming from register elimination. > >> > >> Why isn't this a problem for other targets then? Or maybe it is and t= his > >> shouldn't be a machine specific pass? Maybe postreload-gcse should > >> perform strength reduction (I can't think of any other post reload pas= s > >> that would do something even remotely related). > >> > >> Richard. > >> > > > > It should be a problem for other targets as well (especially RISC-style= ISAs). > > > > It can be easily seen by comparing the generated code for the > > testcases: Example for testcase-2 on AArch64: > > https://godbolt.org/z/GMT1K7Ebr > > Although the patterns in the test cases are the ones that are simple > > as the complex ones manifest in complex programs, the case still > > holds. > > The code for this pass is quite generic and could work for most/all > > targets if that would be interesting. > Interestly enough, fold-mem-offsets seems to interact strangely with the > load/store pair support on aarch64. Note show store2a uses 2 stp > instructions on the trunk, but 4 str instructions with fold-mem-offsets. > Yet in load1r we're able to generate a load-quad rather than two load > pairs. Weird. > I'm confused, where is this comparison from? The fold-mem-offsets pass is only run on RISCV and doesn't (shouldn't) affect AArch64. I only see the 2x stp / 4x str in the godbolt link, but that is gcc vs clang, no fold-mem-offsets involved here. Manolis > jeff