[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

["rakdver at atrey dot karlin dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- 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