------- Comment #12 from zackw at panix dot com 2006-07-13 03:09 ------- Subject: Re: poor optimization choices when iterating over a std::string (probably not c++-specific)
> > I-cache. > this only matters if this increase in code size will make the code go > out of instruction cache. The real program that this is taken from is a large C++ application which is guaranteed to go out of cache - it's got slightly less than four megabytes of .text - the actual goal is to make sure all of its inner inner inner loops do stay in cache. And this is one of 'em. > > Also, more iterations before the branch predictors figure out what's > > going on. > But also possibly more consistent behavior with respect to branch > prediction, in case the loop is often exited in the first iteration. Again, in real life I know a priori that the function is rarely, if ever, called with a zero-length string. ----- I went through the tree dumps for my week-old 4.2.0 for the test program with a fine comb. They are quite instructive. If tree-ch were doing what it says on the label -- copying the loop header -- everything would be fine; dom1 cleans up the two copies of the header later. However, ch isn't just copying the loop header; it is also copying the *entire body of the loop*, which nothing can fix. I call that a clear bug. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
