On Fri, Mar 19, 2010 at 5:09 PM, Ian Bolton <bol...@icerasemi.com> wrote: > Anyway, the reason I mention interblock-scheduling is that I see it > doing seemingly intelligent moves, but then the later BB-reorder pass > is juggling blocks around such that we end up with extra code inside > hot loops! I assume this is because the scheduler and BB-reorderer > are largely ignorant of each other, and so good intentions on the > part of the former can be scuppered by the latter. > > I was wondering if anyone else has witnessed this madness on their > architecture? Maybe it is a bug with BB-reorder? Or maybe it should > only be enabled when function profiling information (e.g. gcov) is > available? Or maybe it is not a high-priority thing for anyone to > think about because no one uses interblock-scheduling?
It's probably a bug in BB-reorder if you end up with extra code in hot loops. BB-reorder can do funny things sometimes, especially if the branch probabilities are estimated. But that seems unlikely in this case because loops are of course taken into account in the estimation. You could check that in the RTL dumps. Enabling BB-reorder only if profile info is available, is not the right way to go. The compiler really doesn't place blocks in sane places without it -- and it shouldn't have to, either. For example if you split an edge at some point, the last thing you want to worry about, is where the new basic block is going to end up. There are actually a few bugs in Bugzilla about BB-reorder, FWIW. Ciao! Steven
