From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.guenther@gmail.com>
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d])
	by sourceware.org (Postfix) with ESMTPS id D2FF43851174
	for <gcc-patches@gcc.gnu.org>; Fri, 28 Oct 2022 12:27:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2FF43851174
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-ed1-x52d.google.com with SMTP id 21so7654689edv.3
        for <gcc-patches@gcc.gnu.org>; Fri, 28 Oct 2022 05:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=2qlyw5S9Uk5YrMXJWnPSmuhz+oH6/eQIf/gAeCjdRk4=;
        b=lyYuGaP1yjA18i7MrXnPImt7jWDUoG05EZL1COtC5mu85hYETOcYJiq9fGRMlRSUZ2
         qNAkQAYwL2QANNq7NFLG0Nd0/JFMcq8NRx3lAXFu9bCaPbaRx2fk3Gd9xOqgurtXsPnw
         SNxxItaFOp4YiRpYnDzjL8ZxAKPPUyIVrLsFh065GS0IdwuAgnP8/UBgL11YlxOPRw9o
         i9UG0tn42CishoVcm/4teo1XRk1Q2KJE14WYGpFzSRAREOMB5glm1tbpofXp9ekg52aT
         EKrTR/W04X/Hkt0iJ0rj09Z+scpkJ/b8wg85pUauA+EisHzbMjBYBdCy5b6iZmG9ECvt
         6/WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=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=2qlyw5S9Uk5YrMXJWnPSmuhz+oH6/eQIf/gAeCjdRk4=;
        b=ynC09EYr4cN5DRpKCUTx5k23QCBp651yfg3dUKRElPDH9tHy5apqn8uCHgAhPKPs0x
         P/wYghMw+UboK0AQf8t8y1IQz70obF4RqQ8LIJgIlaK0FnmVUfyojyYISPH8Qx1/UzIf
         xLyIdvIGS9NCxSCthYW0qExjF5BPyzj8c7r+lCb4OfQ6IyIpSjRDBbnUauT91P/x94nU
         0ulCIdPitri918s1zvTXx6UFNdUwNCYrGt1fCNNjlkq7OGHy0vmXce3fqSMNoFIgIeUM
         A9aekx+rUY9QpyN/Lbt1ZqJFtVrsQlWfSUbd0KiNxql2zV+/8yf43tTAzfrKlVGYGUBC
         TEGg==
X-Gm-Message-State: ACrzQf0OwNZCb83gd32WIwNd7zijSsJuLLi+et5JO2WBiuUcB9ljVqwo
	qbWOC70hSkd357ym9CdIiUF3K7FBppa/9KJpnmcYyxph
X-Google-Smtp-Source: AMsMyM7/JTHQUEgbrft+ZgZbqNTDL93UkIfkVabXLY9cxZoC1wIbnPDCfv5w9qxiVAElaKDFQ0CTmFaVe5OS3+uNzUc=
X-Received: by 2002:a05:6402:3548:b0:45d:6506:990a with SMTP id
 f8-20020a056402354800b0045d6506990amr51177797edd.218.1666960069606; Fri, 28
 Oct 2022 05:27:49 -0700 (PDT)
MIME-Version: 1.0
References: <1930502.usQuhbGJ8B@fomalhaut> <CAFiYyc2xwnpfgzR4zggpjsffecEEMhGA3A3O4pfW+D1eEXJRUw@mail.gmail.com>
In-Reply-To: <CAFiYyc2xwnpfgzR4zggpjsffecEEMhGA3A3O4pfW+D1eEXJRUw@mail.gmail.com>
From: Richard Biener <richard.guenther@gmail.com>
Date: Fri, 28 Oct 2022 14:27:37 +0200
Message-ID: <CAFiYyc2SnnKK3Q1QHSDT3LZ+f3S+tn6Urh3wSrwd51DTKG3S0w@mail.gmail.com>
Subject: Re: [PATCH] Restore RTL alias analysis for hard frame pointer
To: Eric Botcazou <botcazou@adacore.com>
Cc: gcc-patches@gcc.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: <gcc-patches.gcc.gnu.org>

On Fri, Oct 28, 2022 at 2:27 PM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Fri, Oct 28, 2022 at 11:11 AM Eric Botcazou via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
> > Hi,
> >
> > the following change:
> >
> > 2021-07-28  Bin Cheng  <bin.cheng@linux.alibaba.com>
> >
> >         * alias.c (init_alias_analysis): Don't skip prologue/epilogue.
> >
> > broke the alias analysis for the hard frame pointer (when it is used as a
> > frame pointer, i.e. when the frame pointer is not eliminated) described in the
> > large comment at the top of the file, because static_reg_base_value is set for
> > it and, consequently, new_reg_base_value too.  So when the instruction saving
> > the stack pointer into the hard frame pointer in the prologue is processed, it
> > is viewed as a second set of the hard frame pointer and to a different value
> > by record_set, which then resets new_reg_base_value to 0 and the game is over.
> >
> > This e.g. hampers the performance of the var-tracking RTL pass for parameters
> > passed on the stack like on x86, leading to regressions when debugging, but
> > code generation is very likely affected too.
> >
> > Bootstrapped/regtested on x86-64/Linux, OK for mainline and 12 branch?
>
> OK for trunk and 12 after a while of burn-in.

Oh, do you have a testcase suitable for the testsuite?

> Thanks,
> Richard.
>
> >
> > 2022-10-28  Eric Botcazou  <ebotcazou@adacore.com>
> >
> >         * alias.cc (init_alias_analysis): Do not record sets to the hard
> >         frame pointer if the frame pointer has not been eliminated.
> >
> > --
> > Eric Botcazou