Code bloat due to silly IRA cost model?

[Segher Boessenkool]

On Fri, Dec 13, 2019 at 04:22:11PM +0000, Richard Sandiford wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Fri, Dec 13, 2019 at 12:45:47PM +0000, Richard Sandiford wrote:
> >> combine's to blame for the fact that we have two pseudo registers rather
> >> than one.  See the comments about the avr-elf results in:
> >> 
> >>    https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html
> >> 
> >> for more details.
> >
> > It's not combine's fault if register allocation does a bad job.  And we
> > should *not* generate worse code in combine just because it exposes a
> > problem in RA (with 2-2 and make_more_copies we generate better code on
> > average, on all targets I tested, 50 or so).
> >
> > If having two pseudos here is not an advantage, then RA should optimise
> > one away.  It does usually, why not here?
> 
> I didn't say it was combine's fault that RA was bad.  I said it was
> combine's fault that we have two pseudos rather than one.

But that is not a fault, that is on purpose.

Before this change, combine would forward hard registers into pseudos
greedily.  RA can do a better job than that.  If you found a case where
RA does not do a good job, let's fix that?

(And combine does get rid of two pseudos, if that is a good idea to do.
If instructions do not properly combine, it can not, of course).


Segher