On (19/11/06 12:43), Alexander Potapenko wrote:
> > On (19/10/30 15:22), glider@xxxxxxxxxx wrote:
> > > @@ -163,6 +163,11 @@ int stackdepot_memcmp(const unsigned long *u1, const unsigned long *u2,
> > > unsigned int n)
> > > {
> > > for ( ; n-- ; u1++, u2++) {
> > > + /*
> > > + * Prevent Clang from replacing this function with a bcmp()
> > > + * call.
> > > + */
> > > + barrier();
> > > if (*u1 != *u2)
> > > return 1;
> > > }
> >
> > Would 'volatile' do the trick?
> It does. I can replace the barrier with a volatile if you think that's better.
> However this'll add a checkpatch warning, as volatiles are discouraged
> for synchronization (although in this case there's no synchronization)
Yeah, 'volatile' in this case will do what it sort of meant to do - prevent
compiler optimizations. So, like you said, it's not a synchronization issue
and we don't 'volatile' data structures.
Do you need to do barrier() on every iteration? Does clang behave if
you do one barrier() instead of 'n' barrier()-s?
-ss
