This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Optimization of conditional stores
- From: Torvald Riegel <triegel at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Alexander Monakov <amonakov at ispras dot ru>, Roland McGrath <roland at hack dot frob dot com>, Andi Kleen <ak at linux dot intel dot com>, Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org
- Date: Thu, 10 Apr 2014 22:20:58 +0200
- Subject: Re: Optimization of conditional stores
- Authentication-results: sourceware.org; auth=none
- References: <1396652083-18920-1-git-send-email-andi at firstfloor dot org> <20140404234516 dot 3DFAD74446 at topped-with-meat dot com> <20140405003759 dot GQ32556 at tassilo dot jf dot intel dot com> <20140405044201 dot 9B44D74445 at topped-with-meat dot com> <alpine dot LNX dot 2 dot 00 dot 1404071824530 dot 2531 at monopod dot intra dot ispras dot ru> <5342C288 dot 1040107 at redhat dot com>
On Mon, 2014-04-07 at 09:21 -0600, Jeff Law wrote:
> On 04/07/14 08:41, Alexander Monakov wrote:
> > On Fri, 4 Apr 2014, Roland McGrath wrote:
> >>> This is an important optimization to avoid unnecessary cache line
> >>> transitions and aborts. In general unnecessary writes
> >>> can be very expensive in parallel situations, as hardware
> >>> may need to do a lot of work to transition the cache line
> >>> from SHARED to EXCLUSIVE.
> >>>
> >>> I can add a comment.
> >>
> >> I think you might need to do more than that if you want to ensure the
> >> compiler never makes a different choice for you. I'm not positive,
> >> but I think the rules of C allow it to transform the one into the
> >> other ("optimizing out" the test and branch in favor of a write that
> >> might be a no-op). In the absence of volatile (or atomic ops or
> >> whatnot) then I don't think there are any actual guarantees about
> >> anything like e.g. preserving semantics that if the value was already
> >> what you tested for then the page will never see a write access. Even
> >> if compilers don't violate our presumptions about this today, they
> >> might in the future unless the C standard constrains them. And even
> >> if the target hardware in question will never make that a wise
> >> optimization decision and so the compiler will never do it, we should
> >> still express to the compiler the constraints we want it to obey as
> >> best we can. So--unless I'm wrong about what the standard specifies,
> >> which I'm not entirely sure about--then I think we should implement
> >> these cases with something explicit. It could start out as just a
> >> macro that serves as documentation of the intent, while we look into
> >> what we can or should do to express that intent to the compiler. e.g.
> >>
> >> #define assign_probably_same(var, val) ({ if (var != val) var = val; var; })
> >>
> >> (or perhaps get fancier to avoid multiple evaluation or something).
> >
> > The compiler is not allowed to always translate a conditional store:
> >
> > if (*ptr != value)
> > *ptr = value;
> >
> > into an unconditional store, because `ptr' might point to read-only memory.
> >
> > 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.
> You might want to check the C11/C++11 standard to be sure. There's a
> reasonable chance the memory model disallows this kind of transformation.
I think a compiler might consider this as a corner case, in the sense of
as-if potentially allowing an idempotent store. The location is not
atomic-typed (so the compiler can assume thread-local memory is
accessed) nor volatile, so an idempotent store cannot change the outcome
of the program I think -- provided we don't consider read-only memory
(which neither C11 nor C++11 specify, I believe).
However, specific platforms might have read-only memory, so unless a
compiler can prove that the memory is always writable at this point in
time, it might not be wise for the compiler to do the (potentially
idempotent) store all the time.