https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #16 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Wilco from comment #13) > (In reply to Segher Boessenkool from comment #12) > > Before the change combine forwarded all argument (etc.) hard registers > > wherever > > it could, doing part of RA's job (and doing a lousy job of it). If after > > the > > change it no longer two ranges, than a) that is a good decision, or b) there > > is > > some bug in RA. > > I think it's important not to conflate avoiding increasing live ranges of > hard registers and inserting redundant extra moves which cannot be > optimized. The former unconditionally looks like a good idea, however I > can't see any valid reasoning for the latter. Good thing then that that is not what is done! > Basically we now always get 2 moves for every physical register, Huh? The combiner inserts an extra move, yes, but it will always optimise it away again. Unless something in your target code prevents that? (The extra moves are needed because combining a move with some compare or similar can result in a two-output insn, like adds on arm for example). > and this seems to thwart register preferencing. > > > 0.05% code size is nothing, most other biggish changes have a much bigger > > effect. > > Compiler optimization is all about making many small changes which add up to > a large improvement. This is actually quite significant given practically > all code is affected negatively. No, 0.05% code size is nothing. _Especially_ where accompanied by a run time improvement. And it fixes some ICEs, too.
