This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Normalizing the bitmap APIs.
Hi,
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
so.
Ciao,
Michael.