This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix PR 53743 and other -freorder-blocks-and-partition failures (issue6823047)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]