This is the mail archive of the 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: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

> 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?
> Thanks,
> Teresa
> 2013-11-15  Teresa Johnson  <>
>         * 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...


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