------- Comment #18 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-07-13 07:58 ------- 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. how do you define a loop header? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364