This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix PR rtl-optimization/87727


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 <ebotcazou@adacore.com> 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.


Segher


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]