[llvm-dev] Masked intrinsics and non-default address spaces

[Philip Reames via llvm-dev]

I don't think you need to change the signatures to get what you want.

The current definition is:
def int_masked_store : Intrinsic<[], [llvm_anyvector_ty, LLVMPointerTo<0>,
                                       llvm_i32_ty,
                                       LLVMVectorSameWidth<0, llvm_i1_ty>],
                                  [IntrReadWriteArgMem]>;

If I'm remembering my Intrinsics.td syntax correctly, you can simply 
change this to:
def int_masked_store : Intrinsic<[], [llvm_anyvector_ty, llvm_anyptr_ty,
                                       llvm_i32_ty,
                                       LLVMVectorSameWidth<0, llvm_i1_ty>],
                                  [IntrReadWriteArgMem]>;

Philip


On 02/15/2016 11:34 AM, Artur Pilipenko via llvm-dev wrote:
>
> Masked load/store are overloaded intrinsics, the only generic type is 
> the type of the value being loaded/stored. The signature of the 
> intrinsic is generated based on this type. The type of the pointer 
> argument is generated as a pointer to the return type with default 
> addrspace. E.g.:
>
> declare <8 x i32> @llvm.masked.load.v8i32(<8 x i32>*, i32, <8 x i1>, 
> <8 x i32>)
>
> The problem occurs when loop-vectorize tries to use 
> @llvm.masked.load/store intrinsic for a non-default addrspace pointer. 
> It fails with "Calling a function with a bad signature!" assertion in 
> CallInst constructor because it tries to pass a non-default addrspace 
> pointer to the pointer argument which has default addrspace.
>
> My proposal to fix the problem is to add another overloaded type 
> parameter for the intrinsics - the pointer type, which can be any 
> pointer with underlying type being a data type. In this case the 
> signature of the intrinsic above would be:
>
> declare <8 x i32> @llvm.masked.load.v8i32.p1v8i32(<8 x i32> 
> addrspace(1)*, i32, <8 x i1>, <8 x i32>)
>
> Corresponding patch is posted on phabricator: 
> http://reviews.llvm.org/D17270
>
> Any comments, objections or alternatives?
>
> Artur
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160216/ea625b2b/attachment.html>