This is the mail archive of the 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: Normalizing the bitmap APIs.


On Sat, 13 Oct 2012, Lawrence Crowl wrote:

> > > I have no problem in always returning a status change, if you are OK 
> > > with that.
> >
> > I am ok with that.
> There is some rationale for being concerned about performance, as the 
> checking routines need to read memory locations that they otherwise 
> would only write.

If the destination is one of the sources there will be a read anyway.  If 
it's not there will be a small penalty if it isn't in cache yet, though it 
will be soon because of the write.

> I haven't done any performance measures, but I take as evidence that 
> someone thought there was enough of a performance difference to make it 
> worth the extra work of writing a second set of routines.

Nope.  It was valgrind that caused the introduction of the sbitmap _cg 
functions.  If the destination was no input and wasn't initialized the 
computation of the changed flag (and it's comparison with zero) depended 
on uninitialized memory, sometimes flagged by valgrind also when the 
return value wasn't used.

I think it should have been handled by valgrind suppressions, not by 
introducing another interface.

Given this, and that the other bitmap interfaces mostly return a changed 
flag, we should opt for the simpler API, always returning it.  That 
includes the few remaining bitmap.h functions that aren't already doing 


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