[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