This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix PR 53743 and other -freorder-blocks-and-partition failures (issue6823047)
- From: Jeff Law <law at redhat dot com>
- To: Teresa Johnson <tejohnson at google dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Steven Bosscher <stevenb dot gcc at gmail dot com>, David Li <davidxl at google dot com>, reply at codereview dot appspotmail dot com
- Date: Thu, 09 May 2013 22:42:59 -0600
- Subject: Re: Fix PR 53743 and other -freorder-blocks-and-partition failures (issue6823047)
- References: <20130508050850 dot 923A7809EE at tjsboxrox dot mtv dot corp dot google dot com> <CAAe5K+UW5MfcbaHCp+zWTGM9fZvKm6x6no9WDrOOKsap0vvxUQ at mail dot gmail dot com>
On 05/07/13 23:13, Teresa Johnson wrote:
----------------------
Revised patch that fixes failures encountered when enabling
-freorder-blocks-and-partition, including the failure reported in PR 53743.
This includes new verification code to ensure no cold blocks dominate hot
blocks contributed by Steven Bosscher.
Seems like a reasonable verification; presumably if we have a cold block
dominating a hot block, then the block/edge frequencies are badly
broken. Ah, just saw the comments for the other case where this
happens. cold entry, but hot loop inside pushing over the barrier.
Arguably given a cold block in the dominator graph, all its children
should have their frequences scaled down to avoid that situation.
Additionally, I added a flag to the rtl_data structure to indicate whether
any partitioning was actually performed, so that optimizations which were
conservatively disabled whenever the flag_reorder_blocks_and_partition
is enabled (e.g. try_crossjump_to_edge, part of connect_traces) can be less
conservative for functions where no partitions were formed (e.g. they are
completely hot).
----------------------
Ok for trunk?
I can't really comment on the cfglayout and related stuff -- it was
added at a time when I wasn't doing much with GCC and thus I don't know
much about it.
However, I like the changes to record if we've done partitioning and
checking those instead of flag_reorder_blocks_and_partition. That's
simple enough that I'd support pulling it out as a separate patch and
installing immediately if that can be done so without major headaches.
I think we could do something similar with the code to verify the idom
of a hot block is also hot. Though looking at the implementation I
wonder if it could be simplified by walking the dominator tree? I can't
look at it real closely tonight though.
Could you pull those two logical hunks of work out into individual
patches.
jeff