Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] LLVM Concurrency and Undef"
2011 Aug 23
1
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 8:46 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
>> <santosh.nagarakatte at gmail.com> wrote:
>>> Hi all,
>>>
>>> I have been trying to understand the use of undef in
2011 Sep 17
0
[LLVMdev] LLVM Concurrency and Undef
On Tue, Aug 23, 2011 at 12:08 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 8:46 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
>>> <santosh.nagarakatte at gmail.com>
2011 Aug 22
3
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
> <santosh.nagarakatte at gmail.com> wrote:
>> Hi all,
>>
>> I have been trying to understand the use of undef in both sequential
>> and concurrent programs.
>>
>> >From the LLVM Language Reference Manual, I
2011 Aug 22
0
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
>> <santosh.nagarakatte at gmail.com> wrote:
>>> Hi all,
>>>
>>> I have been trying to understand the use of undef in
2011 Aug 22
2
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
>>> <santosh.nagarakatte at gmail.com>
2011 Aug 22
2
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 3:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
>>> <santosh.nagarakatte at gmail.com>
2011 Aug 22
0
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 2:49 PM, Santosh Nagarakatte
<santosh.nagarakatte at gmail.com> wrote:
> Hi all,
>
> I have been trying to understand the use of undef in both sequential
> and concurrent programs.
>
> >From the LLVM Language Reference Manual, I see the following
> definition of undef.
> "Undef can be used anywhere a constant is expected, and indicates
2011 Aug 22
0
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 4:20 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>> On
2011 Aug 23
0
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 7:27 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Mon, Aug 22, 2011 at 3:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>> On Mon, Aug 22, 2011 at 6:08 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>> On
2011 Aug 23
1
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 7:35 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Mon, Aug 22, 2011 at 4:20 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> On Mon, Aug 22, 2011 at 6:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>>> On
2011 Aug 23
1
[LLVMdev] LLVM Concurrency and Undef
On Mon, Aug 22, 2011 at 5:29 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> On Mon, Aug 22, 2011 at 7:27 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
>> On Mon, Aug 22, 2011 at 3:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 3:40 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>>> On
2011 Aug 22
0
[LLVMdev] Reviving the new LLVM concurrency model
On Mon, Aug 22, 2011 at 3:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 11:17 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> On Mon, Aug 22, 2011 at 1:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 9:55 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>>> In
2011 Aug 22
4
[LLVMdev] Reviving the new LLVM concurrency model
On Mon, Aug 22, 2011 at 11:17 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> On Mon, Aug 22, 2011 at 1:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 9:55 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>> In the definition of 'monotonic' ordering,
>>> ... "If an address is written
2011 Sep 11
2
[LLVMdev] LLVM Concurrency and Undef
On Aug 22, 2011, at 5:29 PM, Eli Friedman wrote:
>> LLVM Atomics and Concurrency guide also states the following
>> "Note that speculative loads are allowed; a load which is part of a
>> race returns undef, but does not have undefined behavior"
>>
>> If the speculative loads returns an undef and the returned value is
>> used, then it results in an
2011 Aug 22
2
[LLVMdev] Reviving the new LLVM concurrency model
On Mon, Aug 22, 2011 at 9:55 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> In the definition of 'monotonic' ordering,
> ... "If an address is written monotonically by one thread, and other
> threads monotonically read that address repeatedly, the other threads
> must eventually see the write"...
It's supposed to mean that if you have a something
2011 Aug 22
0
[LLVMdev] Reviving the new LLVM concurrency model
On Mon, Aug 22, 2011 at 3:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 11:17 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> On Mon, Aug 22, 2011 at 1:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 9:55 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>>>> In
2011 Aug 22
0
[LLVMdev] Reviving the new LLVM concurrency model
On Mon, Aug 22, 2011 at 1:02 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Aug 22, 2011 at 9:55 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> In the definition of 'monotonic' ordering,
>> ... "If an address is written monotonically by one thread, and other
>> threads monotonically read that address repeatedly, the other
2011 Jul 31
3
[LLVMdev] Reviving the new LLVM concurrency model
On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
> The current memory model section ends with the following discussions:
>
> "Note that in cases where none of the atomic intrinsics are used, this
> model places only one restriction on IR transformations on top of what
> is required for single-threaded execution: introducing a store to a
2011 Aug 01
0
[LLVMdev] Reviving the new LLVM concurrency model
On Sun, Jul 31, 2011 at 7:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Sun, Jul 31, 2011 at 3:04 PM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote:
>> The current memory model section ends with the following discussions:
>>
>> "Note that in cases where none of the atomic intrinsics are used, this
>> model places only one restriction on
2011 Jul 19
8
[LLVMdev] Reviving the new LLVM concurrency model
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