https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249
--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to Richard Earnshaw from comment #7) > (In reply to Segher Boessenkool from comment #4) > > That is code *size*. Code size is expected to grow a tiny bit, because of > > *better* register allocation. > > > > But we could not do make_more_copies at -Os, if that helps? (The hard > > register > > changes themselves are required for correctness). > > In this case, however, we get *worse* register allocation, since it is using > the the expensive register more frequently than a cheaper register which is > hardly used at all. > > In this particular case, all the uses of the "cheap" register (r7) could use > the 'expensive' register at no additional cost, since the cheap register is > being used only to hold a value that will be moved to another register (a > cheap operation regardless of the register used). FTR, I don't think the combine changes are directly implicated in this regression. They just expose a latent issue with register allocation and its costing.
