[LLVMdev] Reviving the new LLVM concurrency model
jianzhou at seas.upenn.edu
Sun Jul 31 20:16:34 PDT 2011
C++ and Java memory models impose restrictions for locks and unlocks,
such as a thread that releases a lock must acquired the lock, or the
number of locks must be larger than the number of unlocks in the same
thread... for enabling some optimizations, for example, simplifying
and moving some instructions inside lock acquires
(http://www.hpl.hp.com/techreports/2005/HPL-2005-217R1.html). What is
the rationale that the LLVM memory model ignores such restrictions?
On Mon, Jul 18, 2011 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> There was some discussion a while back about adding a C++0x-style
> memory model and atomics for LLVM a while back
> (http://thread.gmane.org/gmane.comp.compilers.llvm.devel/31295), but
> it got stalled. I'm going to try and restart progress on it.
> Attached are two patches; the first adds a section to LangRef with
> just the memory model, without directly changing the documentation or
> implementation of atomic intrinsics. This mostly comes from
> but it's been modified a bit, so please look at the attached version.
> The second fixes the one place I know of where LLVM violates that
> proposed memory model.
> I would appreciate any reviews (primarily for the LangRef bits; I'm
> reasonably confident the patch to LICM is correct).
> There was some discussion about allowing targets to implement
> unaligned stores by widening, but I've left that out. No current
> backend uses such an implementation, so there isn't a substantial
> benefit, and allowing it would break some current optimizations (like
> transforming a memset to an unaligned store). See also the FIXME in
> the LangRef patch about architectures without a proper single-byte
> store instruction.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev