This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Java segfault in predict.c


Hello.

> > > Again, this seems like a real opportunity to want to rely on
> > > monotonicly increasing indicies...
> > 
> > Why?
> 
> So that we don't have to search for the start, obviously. 
> It'll be the lowest numbered block.

Even sbitmap_first_set_bit searches whole bitmap from start; I agree it
is significantly faster then searching the chain. But this is invoked
once per each loop found and I would be very surprised if it was
performance critical.

But what is more interesting: first and last fields are not used for
anything meaningful anywhere (for dumping info about loops in cfgloop
and loop.h; the only place where it plays any role is in predict.c to
make iterating over loop in estimate_probability faster -- and it will
be removed once (if?) we merge the loop changes from cfgbranch.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]