[Bug c++/55135] Segfault of gcc on a big file

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135

--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-06 12:23:21 UTC ---
On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
> 
> --- Comment #28 from Steven Bosscher <steven at gcc dot gnu.org> 2013-03-06 12:18:01 UTC ---
> (In reply to comment #22)
> > Posted for discussion here:
> > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00193.html
> 
> OT: Another trivial speed-up for bitmaps used as regsets (and probably
> in general) is to look at head->first if head->current is not the element
> containing the sought bit, and *not* update head->current if head->first
> is the right element.  This speeds up regsets because a common access
> pattern is to look at sets containing both pseudos and hardregs, and on
> most targets all hardregs are in head->first.  Not updating head->current
> preserves a pointer to the latest accessed pseudos.
> 
> I'll implement this idea and come back with some timings.

Indeed a nice idea ;)  I suppose ->current should only be updated
if its new distance to head->first is bigger than <magic number>
(and zero is of course an obvious one)