<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 8, 2014, at 2:13 PM, Aaron Watry <<a href="mailto:awatry@gmail.com">awatry@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Mon, Sep 8, 2014 at 12:12 PM, Matt Arsenault <<a href="mailto:arsenm2@gmail.com">arsenm2@gmail.com</a>> wrote:<br><blockquote type="cite"><br>On Sep 8, 2014, at 12:52 PM, Aaron Watry <<a href="mailto:awatry@gmail.com">awatry@gmail.com</a>> wrote:<br><br><blockquote type="cite">From CL v1.2, Section 6.12.11:<br>int atomic_max (volatile __global int *p, int val)<br>unsigned int atomic_max (volatile __global unsigned int *p, unsigned int val)<br>int atomic_max (volatile __local int *p, int val)<br>unsigned int atomic_max (volatile __local unsigned int *p, unsigned int val)<br><br>I'm assuming that the pointer declaration as volatile should translate<br>directly to the statement in the bitcode. Let me know if you think I<br>mis-understood that. If that's the case, then we also need to fix the<br>atomic_add and atomic_sub functions.<br></blockquote><br>Yes, that’s how I would interpret it.<br><blockquote type="cite"><br>And yes, there's a note that the atom_* functions from CL 1.0 are<br>still supported. Those functions do NOT define the pointers as<br>volatile.<br></blockquote><br>Yes, the sets of atomic functions are separate. It looks like currently atom_add is defined to be the same as atomic_add<br><br></blockquote><br>I'd tend to agree with that statement.<br><br>Do you want any changes to this patch, or are we good?<br></div></blockquote><div><br></div><div>It’s fine, although it would make sense to add both the atomic_ and atom_ versions at the same time</div><div><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>I'm currently trying to get atomic_max done because cppamp-driver-ng<br>requires it, but eventually I'll probably get around to adding the<br>other missing atomic_* functions and then the wrappers from CL1.0<br>atom_* functions.<br><br>--Aaron<br><br><blockquote type="cite"><br><br><blockquote type="cite"><br>--Aaron<br><br>--Aaron<br><br><br>On Mon, Sep 8, 2014 at 11:41 AM, Matt Arsenault <<a href="mailto:arsenm2@gmail.com">arsenm2@gmail.com</a>> wrote:<br><blockquote type="cite"><br>On Sep 8, 2014, at 12:31 PM, Aaron Watry <<a href="mailto:awatry@gmail.com">awatry@gmail.com</a>> wrote:<br><br><blockquote type="cite">Not used yet...<br><br>Signed-off-by: Aaron Watry <<a href="mailto:awatry@gmail.com">awatry@gmail.com</a>><br>---<br>generic/include/clc/atomic/atomic_max.h | 3 +++<br>generic/include/clc/clc.h | 1 +<br>generic/lib/atomic/atomic_impl.ll | 12 ++++++++++++<br>3 files changed, 16 insertions(+)<br>create mode 100644 generic/include/clc/atomic/atomic_max.h<br><br>diff --git a/generic/include/clc/atomic/atomic_max.h b/generic/include/clc/atomic/atomic_max.h<br>new file mode 100644<br>index 0000000..30dc180<br>--- /dev/null<br>+++ b/generic/include/clc/atomic/atomic_max.h<br>@@ -0,0 +1,3 @@<br>+#define __CLC_FUNCTION atomic_max<br>+#include <clc/atomic/atomic_decl.inc><br>+#undef __CLC_FUNCTION<br>diff --git a/generic/include/clc/clc.h b/generic/include/clc/clc.h<br>index b8c1cb9..b492c54 100644<br>--- a/generic/include/clc/clc.h<br>+++ b/generic/include/clc/clc.h<br>@@ -143,6 +143,7 @@<br>#include <clc/atomic/atomic_add.h><br>#include <clc/atomic/atomic_dec.h><br>#include <clc/atomic/atomic_inc.h><br>+#include <clc/atomic/atomic_max.h><br>#include <clc/atomic/atomic_sub.h><br><br>/* cl_khr_global_int32_base_atomics Extension Functions */<br>diff --git a/generic/lib/atomic/atomic_impl.ll b/generic/lib/atomic/atomic_impl.ll<br>index 9df5b9f..4e228e8 100644<br>--- a/generic/lib/atomic/atomic_impl.ll<br>+++ b/generic/lib/atomic/atomic_impl.ll<br>@@ -10,6 +10,18 @@ entry:<br>ret i32 %0<br>}<br><br>+define i32 @__clc_atomic_max_addr1(i32 addrspace(1)* nocapture %ptr, i32 %value) nounwind alwaysinline {<br>+entry:<br>+ %0 = atomicrmw volatile max i32 addrspace(1)* %ptr, i32 %value seq_cst<br>+ ret i32 %0<br>+}<br></blockquote><br>Why is it necessary to mark these with volatile (though I never remember whether it’s the atom_* or atomic_* functions which is supposed to be volatile)<br><br><br><blockquote type="cite">+<br>+define i32 @__clc_atomic_max_addr3(i32 addrspace(3)* nocapture %ptr, i32 %value) nounwind alwaysinline {<br>+entry:<br>+ %0 = atomicrmw volatile max i32 addrspace(3)* %ptr, i32 %value seq_cst<br>+ ret i32 %0<br>+}<br>+<br>define i32 @__clc_atomic_sub_addr1(i32 addrspace(1)* nocapture %ptr, i32 %value) nounwind alwaysinline {<br>entry:<br>%0 = atomicrmw volatile sub i32 addrspace(1)* %ptr, i32 %value seq_cst<br>--<br>1.9.1<br><br><br>_______________________________________________<br>Libclc-dev mailing list<br><a href="mailto:Libclc-dev@pcc.me.uk">Libclc-dev@pcc.me.uk</a><br>http://www.pcc.me.uk/cgi-bin/mailman/listinfo/libclc-dev</blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br></body></html>