https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #27 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Roger Sayle from comment #21) > Segher has proposed that object code size correlates with the quality of It isn't a proposition, it is a simple and obvious fact. But, this isn't exactly what I say :-) Code size strongly correlates with number of instructions, almost 1-1 on most targets. Number of instructions is exactly what combine tries to reduce. Whether that makes the code actually better is something completely separate as well. If your instruction cost function (and please use insn_cost, it is much easier to use, and thus gives better results than rtx_costs) is good, this of course should work fine. And there is a hook (TARGET_LEGITIMATE_COMBINED_INSN) for the very nasty cases. But the whole "fewer insns that do the same thing, is better" thing is not actually true on some targets. Such targets are incredibly hard to optimise for. There is no way combine can do a good job for such targets. It is incredibly hard for human programmers to write good machine code for such systems by hand as well. I do use object code size **of a huge sample** as a quick and dirty sniff test to see if a change to combines is good or bad. After that I always look at the actual changes as well. I do realise all pitfalls associated with this :-)
