On Mon, Nov 18, 2013 at 3:53 PM, Teresa Johnson wrote: > From a bb layout perspective it seems like it would be beneficial to > do compgotos before layout. Was the current position just to try to > reduce compile time by keeping the block unified as long as possible?
It was more a hack that got out of hand. Apparently it hurt some interpreters (branch prediction!) when the unified computed goto is not "unfactored". There was a PR for this, and the unfactoring code I added only fixed part of the problem. > For your comment "I think those cases would benefit from having at > least scheduling/reordering and alignments done right." do you mean > that it would be better from a code quality perspective for those to > have compgotos done earlier before those passes? That seems to make > sense to me as well. Theoretically: Yes, perhaps. In practice there isn't much to gain. Unfactoring before bb-reorder is probably the most helpful thing, to get better results for basic block alignment and placement. But scheduling punts on computed gotos (or explodes in some non-linear bottleneck). What used to help is profile-based branch speculation, i.e. if (*target_addr == most_frequent_target_addr) goto most_frequent_target_add; else goto *target_addr; But I'm not sure if our value profiling based optimizations still have this case. > I'm doing an lto profiledbootstrap with the change right now. Is there > other testing that should be done for this change? Can you point me at > lucier's testcase that you refer to above? I found that PR15242 was > the bug that inspired adding compgotos, but it is a small test case so > I'm not sure what I will learn from trying that other than whether > compgotos still kicks in as expected. ISTR it's http://gcc.gnu.org/PR26854 Ciao! Steven
