This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition
- From: Jan Hubicka <hubicka at ucw dot cz>
- 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>, Jan Hubicka <hubicka at ucw dot cz>, David Li <davidxl at google dot com>, steven at gcc dot gnu dot org
- Date: Sat, 16 Nov 2013 09:33:55 +0100
- Subject: Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+VuZwb00Ni76j8ju=9_SnwA7PGsz=YZmnky8QWmM8ZCaw at mail dot gmail dot com>
> When testing with -freorder-blocks-and-partition enabled, I hit a
> verification failure in an LTO profiledbootstrap. Edge forwarding
> performed when we went into cfg layout mode after bb reordering
> (during compgotos) created a situation where a hot block was then
> dominated by a cold block and was therefore remarked as cold. Because
> bb reorder was complete at that point, it was not moved in the
> physical layout, and we incorrectly went in and out of the cold
> section multiple times.
> The following patch addresses that by fixing the layout when we move
> blocks to the cold section after bb reordering is complete.
> Tested with an LTO profiledbootstrap with
> -freorder-blocks-and-partition enabled. Ok for trunk?
> 2013-11-15 Teresa Johnson <firstname.lastname@example.org>
> * cfgrtl.c (fixup_partitions): Reorder blocks if necessary.
computed_gotos just unfactors unified blocks that we use to avoid CFGs with
O(n^2) edges. This is mostly to avoid problems with nonlinearity of other passes
and to reduce the quadratic memory use case to one function at a time.
I wonder if it won't be cleaner to simply unfactor those just before pass_reorder_blocks.
Computed gotos are used e.g. in libjava interpreter to optimize the tight interpretting
loop. I think those cases would benefit from having at least scheduling/reordering
and alignments done right.
Of course it depends on how bad the compile time implications are (I think in addition
to libjava, there was a lucier's testcase that made us to go for this trick) ,
but I would prefer it over ading yet another hack into cfgrtl...
We also may just avoid cfglayout cleanup_cfg while doing computed gotos...