This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Fix PR rtl-optimization/87727
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Vladimir Makarov <vmakarov at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 20 Dec 2018 13:31:34 -0600
- Subject: Re: [patch] Fix PR rtl-optimization/87727
- References: <3499484.ePniFpkjG6@polaris> <CAFiYyc3dpfHipN8MD4Jn+yM+_RMXjWKiqxkztdqOLUiApF7umA@mail.gmail.com> <20181220122357.GP23305@tucnak>
On Thu, Dec 20, 2018 at 01:23:57PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 20, 2018 at 01:15:53PM +0100, Richard Biener wrote:
> > On Thu, Dec 20, 2018 at 12:43 PM Eric Botcazou <firstname.lastname@example.org> wrote:
> > > this is a regression introduced on the SPARC by the somewhat controversial
> > > combiner change for hard registers: the compiler can no longer apply the leaf
> > > registers optimization to a small function so a register window is now used.
> > >
> > > The combiner change might be an overall win, but my understanding is that it's
> > > dependent on the target and SPARC seems to be in the wrong basket: almost all
> > > changes to the gcc.c-torture/compile testsuite at -O2 are pessimizations in
> > > the form of additional move instructions between registers on function entry.
> > >
> > > Clearly that's counter-productive for a LEAF_REGISTERS target like SPARC so
> > > the proposed fix is to re-enable hard register combining for leaf registers.
> > >
> > > Tested on SPARC/Solaris 11, OK for the mainline?
> > This only affects xtensa besides sparc so unless Segher objects this is OK.
> > Does this solve most of the pessimizations?
> > Please add a testcase if it doesn't solve existing FAILs.
> Generally it would be better to deal with that in RA, but if Vlad doesn't
> have cycles for it right now, your hack isn't that bad.
It's not a terrible workaround, no. It looks like it will make some asm
once again fail though? If argument registers are forwarded to in the asm.