Use stacked method tables

[vchuravy]

Companion to JuliaGPU/GPUCompiler.jl#494

[github-actions]

Your PR requires formatting changes to meet the project's style guidelines.
Please consider running Runic (git runic master) to apply these changes.

Click here to view the suggested changes.

diff --git a/src/OpenCL.jl b/src/OpenCL.jl
index 04c0a99..6efcbb3 100644
--- a/src/OpenCL.jl
+++ b/src/OpenCL.jl
@@ -21,9 +21,11 @@ export cl
 Base.Experimental.@MethodTable(method_table)
 
 macro device_override(ex)
-    esc(quote
-        Base.Experimental.@overlay($method_table, $ex)
-    end)
+    return esc(
+        quote
+            Base.Experimental.@overlay($method_table, $ex)
+        end
+    )
 end
 
 macro device_function(ex)
@@ -35,10 +37,12 @@ macro device_function(ex)
         error("This function is not intended for use on the CPU")
     end
 
-    esc(quote
-        $(ExprTools.combinedef(def))
-        @device_override $ex
-    end)
+    return esc(
+        quote
+            $(ExprTools.combinedef(def))
+            @device_override $ex
+        end
+    )
 end
 
 

[maleadt]

😱
That repo is hosted here; just remove the functions from there as well?

[vchuravy]

So this is a good question. Inside SPIRVIntrinsics.jl we will likely want to use device_function and device_override. At least device_function makes sense.

OpenCL.jl/lib/intrinsics/src/atomic.jl

Line 19 in f7d5ae4

@device_function atomic_add!(p::LLVMPtr{$gentype,$as}, val::$gentype) =

For me that means we shouldn't remove these macros, we could rename them to spirv_function or somemthing similar.

[maleadt]

Oh right, SPIRVIntrinsics retains its own method table. In that case, I guess we should start marking functions for export (or use the new @public) and only expose those to the importing package.