-
-
Notifications
You must be signed in to change notification settings - Fork 55
WMMA uses generic addressing #548
Comments
Or fix the LLVM backend? You will probably get the same addrcasts after inlining. |
The problem isn't so much the addrspacecasts themselves, but rather that we call the intrinsic with type On first sight, solving this in the backend will be tricky: the I think the cleanest solution is to add a pointer type annotated with the address space Alternatively, instead of using @maleadt What are your thoughts on this? |
This is the real problem, LLVM might refuse to validate our IR at any point because of it. I've been wanting some way of emitting pointers in specific address spaces for a long time, but |
Hm I see... So the declared type to the intrinsic in ccall is I suspect short-term the generated function will get you there the quickest. I was thinking about maybe fixing this up in codegen, but since the declared types are a missmatch, we would indeed need some representation of addressspace at the Julia level. |
557: Use AddrSpacePtr to call WMMA intrinsics r=vchuravy a=thomasfaingnaert Closes #548 Depends on JuliaLang/julia#34760 Co-authored-by: Thomas Faingnaert <thomas.faingnaert@hotmail.com>
Not sure why I didn't notice this before...
gives:
On the LLVM side, everything looks fine: the
p3
variant for shared memory is used.However, the NVPTX backend selected an
wmma.store.d.sync.aligned.col.m16n16k16.f32
and acvta.shared
instead of just using awmma.store.d.sync.aligned.col.m16n16k16.shared.f32
.This seems to happen because of the addrspacecast to
i8*
, even though the intrinsic has argument typei8 addrspace(3)*
. This confuses the NVPTX backend, which consequently selects the generic WMMA variant.To fix this, I should either make sure that
ccall(..., llvmcall, ...)
respects addrspaces, or extendRef{T}
with an addrspace argumentRef{T, A}
.The text was updated successfully, but these errors were encountered: