On 10/08/2015 06:57 PM, Segher Boessenkool wrote:
As the PR points out, the "simple" reorder algorithm makes bigger code
than the STC algorithm did, for -Os, for x86. I now tested it for many
different targets and it turns out to be worse everywhere.
That's somewhat disappointing. Wasn't it supposed to improve over it?
What went wrong?
Is this okay for trunk?
2015-10-08 Segher Boessenkool <seg...@kernel.crashing.org>
PR rtl-optimization/67864
* gcc/bb-reorder (reorder_basic_blocks_simple): Prefer existing
fallthrough edges for conditional jumps. Don't sort candidate
edges if not optimizing for speed.
Ok. Although it would be nice to understand exactly what causes code
growth and possibly get a real cost estimate rather than such a heuristic.
Bernd
