From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <richard.guenther@gmail.com>
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634])
	by sourceware.org (Postfix) with ESMTPS id 7E5B2385624A
	for <gcc-patches@gcc.gnu.org>; Fri, 28 Oct 2022 12:27:28 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E5B2385624A
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-ej1-x634.google.com with SMTP id sc25so12502005ejc.12
        for <gcc-patches@gcc.gnu.org>; Fri, 28 Oct 2022 05:27:28 -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=vniULAl3eHPCnEKbq3u877sfOyX3Ws4xnd3TlZzvclw=;
        b=BYlinJbfJw/eA08T5OMpAQ0nAxI1WNqpvua5ZuFe2kFAzBmGktEu34CRkKyDH16t7G
         5PhrRSgBBNUHezsbDPLg+ecNXGbRjL4K/Ywms14S4BskhYFmDsB+FgQkA8zQGWHMHtMB
         RdTXaiid8Iy7VG9dQ/7/ihTaUaM0jfneXX5tzrdQ+qYjCdoSM9qg3IsOz7S4ovuNiOAF
         Nw8H3hjTPBPbmmhQr5g7hdYCOCCRiCkjTGe8EqtlmfGIFFMkkKOuYZdBwu9YrW2K/Ofp
         R+T/ssvTGaxHq/Hld3wvb5N/x7v1zCRL3uJ5eWUkVU7MLF6C/5bVzLElVeKREkYNOKMI
         q22g==
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=vniULAl3eHPCnEKbq3u877sfOyX3Ws4xnd3TlZzvclw=;
        b=Zwp+4SVyNM5h4DySelum4URxq8qHFHVyjAktJNEUsYmL8bsMxNcS8TvH+cDueoF/tl
         ZaxcoS/GDLbzViPJ5zedHqWWFomshQIr+Q7Qq9AHhHLL6sfCz2/7h7HdEy+9WEJvF/eO
         /jEnmNpaPWUrMXWf0fF53uNGoAJ8+Buh+e7jHf9zOZHnOzh7gCvFhi638/WBQdMBac/P
         CXZ2gdOIHTjHwAEIRt6Ebi4wFna6jrld703+vXmc8HkU9ptAQBkDj0MHIxN4iz9SZDJp
         iHF/BUJTETeTswArNVjy6TQ4CyAZHXYdxG9jN9cXW0MxUULmTy0R/3ixBobz8QznNNMI
         f/Pg==
X-Gm-Message-State: ACrzQf2K+2LscckzgCN/7b24jhQhnJyeR2hhaWJasEqcKWFaiy80Gk8/
	+dcsuC7/eAqpUO5iK1EWgs9M+rC/P6s7BlhnOi8=
X-Google-Smtp-Source: AMsMyM63wjCQeO3J68+mIeLsUxcqN9MiXwjXXiwtAZT9xhI8f1b9oNz6moJq12U2VcVXUePlrxsmoAQN+hY3Cq9c4EY=
X-Received: by 2002:a17:906:8b81:b0:7ad:93d1:5eae with SMTP id
 nr1-20020a1709068b8100b007ad93d15eaemr6300392ejc.29.1666960047140; Fri, 28
 Oct 2022 05:27:27 -0700 (PDT)
MIME-Version: 1.0
References: <1930502.usQuhbGJ8B@fomalhaut>
In-Reply-To: <1930502.usQuhbGJ8B@fomalhaut>
From: Richard Biener <richard.guenther@gmail.com>
Date: Fri, 28 Oct 2022 14:27:15 +0200
Message-ID: <CAFiYyc2xwnpfgzR4zggpjsffecEEMhGA3A3O4pfW+D1eEXJRUw@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.1 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 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.

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