https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> CCing authors of the other commits. That said, complaining about size
> regressions generally should be only if it (significantly) increases sizes
> of some larger codebases (CSiBE, size of some large app, ...), when looking
> at a single function only, there will be always improvements and
> degradations, the compiler is changing.
A few comments about "my" patch (r228318), the reorder-blocks thing.
First of all, almost all it does is heuristic, so exactly as Jakub
says you have to look at bigger tests. This patch makes -freorder-blocks
use a new algorithm ("simple") for -Os; after a few follow-up patches
this consistently gives smaller code. The big difference with the old
("stc") algorithm is that that one can duplicate blocks, which sometimes
results in smaller code, while "simple" never does. It may be interesting
to look at before and after of just this patch, to see if the heuristics
can be improved.
