From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id D3B9D3858C5E for ; Tue, 23 Jan 2024 14:35:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D3B9D3858C5E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D3B9D3858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::22b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706020506; cv=none; b=UbqnF25k/bkgVkCBZgVV4ZmjhW1ntirPL3p/4k6vDn8TPRAvuzNLU+Ri8TTsbzVQP1UaH9IqBepI6XkKJHO/nmTxLYZx74GB6F8dQonc2l2onFIIU3tiA+fw95JNTDZf8+JfNegmq5q+yCmFuS+zbP/pipjQBBQCCj6OYU8a/OU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706020506; c=relaxed/simple; bh=GCYlrln60DBiLZIDIt9vneV/lJ4JbENIfR0VlfgbfyQ=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=M9eVWzz+yPuFCMIGMD+y7JFF4uTk6oiopb4U7YDuZEdlFP8jx0TKopNN+rQprl0Yic/bejolCPmxYNTX2+TPPY10LonFP/svWynlGHB7wocR7/OJQC/NZ9lHY0rV+uqgYWFa5W7P24XQGajcNQEWYVNwZVvFQ/haUp1Rrei6XTk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x22b.google.com with SMTP id 5614622812f47-3bd7c5b243dso3098892b6e.1 for ; Tue, 23 Jan 2024 06:35:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706020502; x=1706625302; darn=gcc.gnu.org; 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=q+i7WJ7cy2D2nQ9nEdvehRu7e5anhTph2uVV0HBrUkY=; b=UOBHIv8kYkEmmDgx2+BCaDnTlXh2v4wm/GG9C/TCTDO2/YyEKhcbX7ALRFWOAfpPAt JbZuVXSlEov5GfrMJ+zprzC5zL3b5ffojyHsg7LxbjHwBfy1lZUlQPidIl51DSS4Iu/v YO2OFtdhiW6XTQv+nF9mL9mJFic788jfRXSqzYGCGXS60xOWAinXEXwvTV/S5oGzQyke qjovyBCNnbG9b6+iAcRKAUEm9NkhnMY0K2WCI5MWDy49kK179/HFX50kX1q4Gu0Ql57Y KJmMncqMY1uta52IYsE/AelSu4efWMBHLEl8ZYcz6e3LZpTBCmiGw1mIRPpVjQo0xIkL L1OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706020502; x=1706625302; 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=q+i7WJ7cy2D2nQ9nEdvehRu7e5anhTph2uVV0HBrUkY=; b=R7v0e728uC8pPn4yH/z5WOHG0SVIRKjXC+us4YsH2k/kzGjjB94ai/n+Sr2DGe8wb0 VqqwbgqeSo93juqX8ZZo2b9zUlRmVrc17LMDdAEIIZWPftrKE8gOUSHxXKbF5CcPdKm3 0ztZGjohvSu5W6xhK1EYYVC/zayd84mRHeqo/PTDd8IHOqjoUN36vNQaEGph5nUeuWK+ +yNFVzPo3Hu88v5t3r7oDskJ5AxTT1KKIvR8Y0lAlxR2J1SyHxBUeGyynJiCBtOydSp1 pMJQ/K/3Ut79iYsxzMqsH8F2LBaKTmTFLaqghT6e4hThAmoIMPXy82NkEw5mHxfz9mel Dwrg== X-Gm-Message-State: AOJu0Yw9hFfaRsbArC2LTacIEj19Bl+xd1ZS8/doMC3d9RP0AuyZwPH+ 2P3kOZOWxNgT07GJ/pUiyRdEuycGYa5WDwmcEAJnFi72KNgwFVi/bdEgQt408hyzInx6X70Z+nD 603lOw0iSUcHljA+BZ19SdV3rExU= X-Google-Smtp-Source: AGHT+IE+7jRAzZCmnoP4FY4ipp/jzttyc8n1BFdmmQ9PbVs0jJlK4ytilmI1HF81Jx11ZgRHQMA4Cgu00wfSogYl/0I= X-Received: by 2002:a05:6808:f8d:b0:3bd:ca4a:7dab with SMTP id o13-20020a0568080f8d00b003bdca4a7dabmr449566oiw.19.1706020502231; Tue, 23 Jan 2024 06:35:02 -0800 (PST) MIME-Version: 1.0 References: <65a53592.920a0220.cc7a1.f89eSMTPIN_ADDED_MISSING@mx.google.com> <79111s2s-00s7-716o-19q0-q93069o7s983@fhfr.qr> In-Reply-To: From: "H.J. Lu" Date: Tue, 23 Jan 2024 06:34:26 -0800 Message-ID: Subject: Re: [PATCH 1/2] rtl-optimization/113255 - base_alias_check vs. pointer difference To: Richard Biener Cc: Jeff Law , gcc-patches@gcc.gnu.org, jlaw@ventanamicro.com, ebotcazou@adacore.com, Jakub Jelinek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3021.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,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 Tue, Jan 23, 2024 at 6:15=E2=80=AFAM H.J. Lu wrote= : > > On Mon, Jan 22, 2024 at 11:10=E2=80=AFPM Richard Biener wrote: > > > > On Mon, 22 Jan 2024, Jeff Law wrote: > > > > > > > > > > > On 1/15/24 06:34, Richard Biener wrote: > > > > When the x86 backend generates code for cpymem with the rep_8byte > > > > strathegy for the 8 byte aligned main rep movq it needs to compute > > > > an adjusted pointer to the source after doing a prologue aligning > > > > the destination. It computes that via > > > > > > > > src_ptr + (dest_ptr - orig_dest_ptr) > > > > > > > > which is perfectly fine. On RTL this is then > > > > > > > > 8: r134:DI=3Dconst(`g'+0x44) > > > > 9: {r133:DI=3Dframe:DI-0x4c;clobber flags:CC;} > > > > REG_UNUSED flags:CC > > > > 56: r129:DI=3Dconst(`g'+0x4c) > > > > 57: {r129:DI=3Dr129:DI&0xfffffffffffffff8;clobber flags:CC;} > > > > REG_UNUSED flags:CC > > > > REG_EQUAL const(`g'+0x4c)&0xfffffffffffffff8 > > > > 58: {r118:DI=3Dr134:DI-r129:DI;clobber flags:CC;} > > > > REG_DEAD r134:DI > > > > REG_UNUSED flags:CC > > > > REG_EQUAL const(`g'+0x44)-r129:DI > > > > 59: {r119:DI=3Dr133:DI-r118:DI;clobber flags:CC;} > > > > REG_DEAD r133:DI > > > > REG_UNUSED flags:CC > > > > > > > > but as written find_base_term happily picks the first candidate > > > > it finds for the MINUS which means it picks const(`g') rather > > > > than the correct frame:DI. This way find_base_term (but also > > > > the unfixed find_base_value used by init_alias_analysis to > > > > initialize REG_BASE_VALUE) performs pointer analysis isn't > > > > sound. The following restricts the handling of multi-operand > > > > operations to the case we know only one can be a pointer. > > > > > > > > This for example causes gcc.dg/tree-ssa/pr94969.c to miss some > > > > RTL PRE (I've opened PR113395 for this). A more drastic patch, > > > > removing base_alias_check results in only gcc.dg/guality/pr41447-1.= c > > > > regressing (so testsuite coverage is bad). I've looked at > > > > gcc.dg/tree-ssa tests and mostly scheduling changes are present, > > > > the cc1plus .text size is only 230 bytes worse. With the this > > > > less drastic patch below most scheduling changes are gone. > > > > > > > > x86_64 might not the very best target to test for impact, but > > > > test coverage on other targets is unlikely to be very much better. > > > > > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu (together > > > > with 2/2). Jeff, can you maybe throw this on your tester? > > > > Jakub, you did the PR64025 fix which was for a similar issue. > > > No issues across the cross compilers with those two patches. > > > > Thanks, pushed. I'm probably going to revert when bigger issues > > appear (and hopefully we'd get some test coverage then). > > > > Richard. > > The test failed with -m32: > > FAIL: gcc.dg/torture/pr113255.c -O1 (test for excess errors) > Excess errors: > cc1: error: '-mstringop-strategy=3Drep_8byte' not supported for 32-bit co= de > I am checking in this: diff --git a/gcc/testsuite/gcc.dg/torture/pr113255.c b/gcc/testsuite/gcc.dg/torture/pr113255.c index 2f009524c6b..78af6a5a563 100644 --- a/gcc/testsuite/gcc.dg/torture/pr113255.c +++ b/gcc/testsuite/gcc.dg/torture/pr113255.c @@ -1,5 +1,5 @@ /* { dg-do run } */ -/* { dg-additional-options "-mtune=3Dk8 -mstringop-strategy=3Drep_8byte" { target { x86_64-*-* i?86-*-* } } } */ +/* { dg-additional-options "-mtune=3Dk8 -mstringop-strategy=3Drep_8byte" { target { { i?86-*-* x86_64-*-* } && { ! ia32 } } } } */ struct S { unsigned a[10]; unsigned y; unsigned b[6]; } g[2]; --=20 H.J.