This is the mail archive of the
mailing list for the GCC project.
Re: Normalizing the bitmap APIs.
On 10/15/12, Michael Matz <firstname.lastname@example.org> wrote:
> 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 agree that if the destination is a source, there is little cause
for concern. However, there are routines in which the definition
is write only.
> > 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.
Does anyone have objections to this plan?