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 10/15/12, Michael Matz <> 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?

Lawrence Crowl

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