similar to: [LLVMdev] LLVM Concurrency and Undef

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