Re: [PATCH] Restore RTL alias analysis for hard frame pointer

[Richard Biener <richard.guenther@gmail.com>]

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