Hi Mon Wang,
As I understand it the C++0x memory model will, by default, be similar
to Java's in that it will assume sequential consistency, using
acquire/release atomics (similar to Java's volatile), for all programs
that do not contain data races. Unlike Java in the case when a program
contains a data race, the program behavior is undefined. Adopting this
model allows many sequential compiler optimizations to be applied within
the context of a single thread; although register optimizations, such as
promotion, are not always valid. Of course, the problem with this
approach is that it is often the case that compiler/hardware cannot
reorder accesses to gain optimal performance and in light of this C++0x
allows values of type atomic to be accessed through a relaxed
consistency model, e.g.
x.load(memory_order_relaxed);
x.store(something, memory_order_relaxed);
In this case the compiler is free to order load/stores to x, in
different threads, any why it feels fit. The full set of relaxed options
are defined by the enumeration:
typedef enum memory_order {
memory_order_relaxed, memory_order_acquire,
memory_order_release,
memory_order_acq_rel, memory_order_seq_cst
} memory_order;
In the case of a default consistency model memory fences are not
required but, in general, this is no longer the case for the relaxed
model and C++ provides a family of fence operations, one per type of
atomic (i.e. bool, address, and integral types); the bool fence
operation is declared as:
void atomic_fence( const volatile atomic_bool*, memory_order );
One interesting point is that C++0x defines fences for operations and
not just load and stores. I am not completely sure of the implications
with respect to mapping to LLVM but note that this is relaxed a little
by providing per-variable fence operations, implemented as
read-modify-write instructions, which is similar to those provided by
LLVM.
Anyway I have probably strayed of topic for this list and so will stop
now.
Ben
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Mon P Wang
Sent: Tuesday, July 15, 2008 6:18 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] addrspace attribute and intrisics
Hi Ben,
Vacation is always a good thing. Hope you had a good one.
In my mind, having a more general memory consistency model is going to
be very useful in LLVM in the future. It is still a little unclear to
me what we should support. I haven't looked at what C++ is
considering for their model. Are they going to support different
relaxations models like relaxing write to read or write order, read
others and write early?
In terms of what I'm doing now, I was planning to put in intrinsics
with memory spaces first and then later on add in the memory barrier
that takes an optional memory space argument.
BTW, for the name of the intrinsics, it was simpler to define the
intrinsic names to be return type
followed by any parameter, e.g.,
@llvm.atomic.load.add.i32.p0i32 // returns i32, i32 ptr to
default address space
@llvm.atomic.load.add.i32.p11i32 // return i32, i32 ptr to
address space 11
-- Mon Ping
On Jul 14, 2008, at 2:58 AM, Benedict Gaster wrote:
> Hi Mon Ping,
>
> Sorry for the slow reply but I have been out on vacation.
>
> Originally I thought that Sun's latest ISAs support barriers with
> explicit address but looking at this now I cannot find a reference to
> this and so agree that this may be a useful feature at this time. One
> area where this may be useful in the future is with regard to the
> memory model that C++ is considering, it allows specific variables to
> be type atomic<T> that can be accessed in a relaxed manner (by
default
> access is not relaxed). In this case fence operations will be
> required, possibly at the granularity of a single variable access.
>
> I agree that there does not seem a strong argument for the more
> general memory fence operation and given the not very nice semantics,
> it would make sense to go with something along the lines of a barrier
> operation with an (optional) memory space argument. Is it your
> intention to add a generalized version along with your changes for
> supporting intrinsics with address spaces?
>
> Ben
>
> On 7 Jul 2008, at 22:24, Mon P Wang wrote:
>
>> Hi Ben,
>>
>> Sorry, I didn't read carefully enough your point on a generic
memory
>> fence. I don't like the semantics that the compiler needs to
>> determine if a pointer has a valid address or not to determine the
>> semantics of the operation. In your original email, you indicate you
>> propose another field "barrier" that indicates if the barrier
applies
>> to the entire space that the pointer points to or to the location
>> that
>> ptr points to, i.e.,
>> declare void @llvm.memory.fence( i1 <ll>, i1 <ls>, i1
<sl>, i1 <ss>,
>> i32
>> addrspace(11)*<ptr>, i1 <device>, i1 barrier )
>>
>> That would work but I don't particular like it. It seems cleaner if
>> we
>> could overload the signature such that if given an integer, it treats
>> it as a barrier for the address space or if we given a pointer, we
>> can
>> treat it as a barrier to that location.
>>
>> One question that I have is what are the typical use cases for the
>> more generic memory barrier. Do current hardware support barrier
>> on a
>> particular element or do they specify it for a range of addresses?
>>
>>
>> -- Mon Ping
>>
>>
>> On Jul 7, 2008, at 12:21 PM, Benedict Gaster wrote:
>>
>>> I agree that if we intend that the it is always a complete barrier,
>>> but it is possible for a more general memory fence operation that
>>> has
>>> the ability to place a barrier on the region of memory that %ptr11
>>> points to but in the case that it does not point to a valid address
>>> then it is assumed to be a complete barrier for that address space.
>>> As
>>> sum types are not directly support in LLVM, then this semantics has
>>> to
>>> be supported with an additional argument describing which
injection,
>>> i.e. if it is a valid address or not, the type of %ptr11 is passed.
>>>
>>> Ben
>>>
>>>
>>> On 7 Jul 2008, at 17:15, Mon P Wang wrote:
>>>
>>>> g the address space argument is cleaner
>>>> than having it encoded as a pointer. The memory barrier places
a
>>>> barrier on the entire address space. When I see the %ptr11 on
the
>>>> memory barrier instruction, my first instinct is to that it is
a
>>>> memory barrier on the region of memory that %ptr11 points to.
What
>>>> are other people opinions?
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev