This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: Optimization of conditional stores (was: Re: [PATCH] Add adaptive elision to rwlocks)



On Mon, 7 Apr 2014, Andi Kleen wrote:

> > If the compiler can prove that `ptr' must be pointing to writeable location
> > (for instance if there is a preceding (dominating) unconditional store), it
> > can, and likely will, perform the optimization.
> 
> Except it's not an optimization, but a pessimization

I see where you're coming from, but is that really a pessimization for a case
of non-multithreaded execution?  Also, I (of course) agree with Jeff Law that
such transformation has good chances of violating the memory model imposed by
newer standards.

> Which compiler would do that? It sounds very broken to me.

Example:

void foo(int * __restrict__ ptr, int val, volatile int * __restrict__ cond)
{
  *ptr = 0;
  while (*cond);
  if (*ptr != val)
    *ptr = val;
}

In my tests, GCC versions before 4.8 optimize out the first store and the
conditional branch.  GCC 4.8.0 preserves both the first store and the branch.
If you omit the busy-wait loop, GCC 4.8 performs the optimization as well.

> > I would also suggest making the intent (perform the store only when necessary)
> > explicit, and make sure to disallow the compiler optimization, for example:
> > 
> >     if (*ptr != value)
> >         *(volatile typeof(*ptr)*)ptr = value;
> 
> That's really ugly.

I simply expanded kernel's ACCESS_ONCE macro by hand for the sake of the
example.

Alexander


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