From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 113823857351 for ; Tue, 18 Jul 2023 17:15:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 113823857351 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-pg1-x52b.google.com with SMTP id 41be03b00d2f7-55b83ae9be2so4544474a12.2 for ; Tue, 18 Jul 2023 10:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1689700544; x=1692292544; 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=33FKnJP73JKmHRnNchGtQIHK4+c6cUZ1n5LUAcOai70=; b=Iyqg8Lhudrq+W2s58uTmu4oI2rp7isd6a9NqEL175qK8H7jBbSuzfK/pb6I17Hd7E6 XGiGUg+M/FlQsTURW6d0yBfVH2XYDG1I/G4UIzIvsSJEQVK/Bj1Srigd2eC0d5OBc40P pmcWIno/Z2j6OTNrxHRmUqK4Q9yx0MsYTW1FG4UepKtWaHCG155PalcYrYQIpiAM+1Ny 6PbygqJKWyGm2QBbUegc0o/LcPeRmhzpKqhzoD4HGoPBydSi/cLajq0rFEImBef82h8E a9iHxw9j9J6QCmNNq/dAcn6PHBDXCUEnteej3uKTxEE6lGAsfTfU4QQyQS2dVlAcnqJV 0ijg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689700544; x=1692292544; 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=33FKnJP73JKmHRnNchGtQIHK4+c6cUZ1n5LUAcOai70=; b=SMxZMlZuf0OWDLODanRCaFlA06qwYEz1hhWLvbK7sFGVK0817o93IdfW4XErUGFSCW 4Cn7sWpdVEklyQNoPxXvXZZhfep/iJiTJUBrxWk6ktrjQU6clFw1/5/eWt+qCh7yxn4s x6GPDcLJ0IvWF+ZNbju66s/VieW0SBNsGIHmpfH8h26eZVLNciT0wlPw/HSbcAwv4LYj cfJg+la7UFPSeRhfTKPL5Y2SAqC25dfFNhO1Ib1pjqdPXD5hQALUdfrE0e58PnHsBSr6 kwQ37dJ0/wATteR9TORJ1JkYySdkTNjMy6QcRzF0/cYr1lFKLy/SxZlritOo2Nz+eF7u Shzw== X-Gm-Message-State: ABy/qLbC+SwPeTy/OOGp0bkjlfBt4BlPmEpJKMrt5CDONsFut/W117q/ zK+i8EyyjtJ2t7bKSCgh5SNGoqnHtii/w7P/5Q8mvw== X-Google-Smtp-Source: APBJJlGjHMtYvvmslJgogR0fTg4JuuBS48MTVMTYyJ6IXfaqJGOFDv+5k0/hOALFIWSRBLLF92MPoAW2y+I2hO++DPs= X-Received: by 2002:a17:90a:410e:b0:263:f583:a6a1 with SMTP id u14-20020a17090a410e00b00263f583a6a1mr14620222pjf.34.1689700542798; Tue, 18 Jul 2023 10:15:42 -0700 (PDT) MIME-Version: 1.0 References: <20230713141336.3950751-1-manolis.tsamis@vrull.eu> <1420ed26-9c30-b09e-f45c-54c89516814e@gmail.com> In-Reply-To: <1420ed26-9c30-b09e-f45c-54c89516814e@gmail.com> From: Manolis Tsamis Date: Tue, 18 Jul 2023 20:15:06 +0300 Message-ID: Subject: Re: [PATCH v3] Implement new RTL optimizations pass: fold-mem-offsets. To: Jeff Law Cc: gcc-patches@gcc.gnu.org, Philipp Tomsich , Richard Biener , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.0 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 Fri, Jul 14, 2023 at 8:35=E2=80=AFAM Jeff Law wr= ote: > > > > 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. Thanks, Manolis > Jeff