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

["zackw at panix dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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