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 <ebotca...@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
