[Libclc-dev] [PATCH] R600: Use new barrier intrinsic
Matt Arsenault via Libclc-dev
libclc-dev at lists.llvm.org
Thu Jul 14 23:48:32 PDT 2016
> On Jul 14, 2016, at 20:03, Aaron Watry <awatry at gmail.com> wrote:
>
> Re-adding libclc to CC list.... oops.
>
> On Thu, Jul 14, 2016 at 10:03 PM, Aaron Watry <awatry at gmail.com <mailto:awatry at gmail.com>> wrote:
> From 02c998f017107153c6dc78b8eb58192bfc338d80 Mon Sep 17 00:00:00 2001
> From: Matt Arsenault <matthew.arsenault at Amd.com>
> Date: Wed, 13 Jul 2016 21:07:53 -0700
> Subject: [PATCH] R600: Use new barrier intrinsic
>
> ---
> r600/lib/synchronization/barrier_impl.ll | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/r600/lib/synchronization/barrier_impl.ll b/r600/lib/synchronization/barrier_impl.ll
> index 825b2eb..9b8fefb 100644
> --- a/r600/lib/synchronization/barrier_impl.ll
> +++ b/r600/lib/synchronization/barrier_impl.ll
> @@ -1,7 +1,6 @@
> declare i32 @__clc_clk_local_mem_fence() #1
> declare i32 @__clc_clk_global_mem_fence() #1
> -declare void @llvm.AMDGPU.barrier.local() #0
> -declare void @llvm.AMDGPU.barrier.global() #0
> +declare void @llvm.r600.group.barrier() #0
>
> define void @barrier(i32 %flags) #2 {
> barrier_local_test:
> @@ -11,7 +10,7 @@ barrier_local_test:
> br i1 %1, label %barrier_local, label %barrier_global_test
>
> barrier_local:
> - call void @llvm.AMDGPU.barrier.local()
> + call void @llvm.r600.group.barrier()
>
> Please pardon my ignorance, but does the new intrinsic handle synchronizing writes/reads to local/global memory along with thread synchronization?
>
> If that is the case, could we modify the barrier_local portion to jump straight to done, so that we don't end up inserting two barriers if someone calls
> barrier(CLK_GLOBAL_MEM_FENCE | CLK_LOCAL_MEM_FENCE);
>
> I don't have my NI card installed at the moment, but could if necessary to test things out.
>
> --Aaron
>
No, but the old intrinsics didn’t either. There is only one synchronization instruction, the memory fence is a different problem. I don’t think it actually matters with the constraint that global memory is only consistent within a workgroup, although I”m less sure how the old hardware caches worked
-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libclc-dev/attachments/20160714/4a5e6c6b/attachment.html>
More information about the Libclc-dev
mailing list