This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] bb-reorder: Improve the simple algorithm for -Os (PR67864)
- From: Bernd Schmidt <bschmidt at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 9 Oct 2015 12:35:46 +0200
- Subject: Re: [PATCH] bb-reorder: Improve the simple algorithm for -Os (PR67864)
- Authentication-results: sourceware.org; auth=none
- References: <c792164a9e6f8c4ba4db346c2df0e2341c73a3df dot 1444322573 dot git dot segher at kernel dot crashing dot org>
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 <segher@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