[llvm-dev] Masked intrinsics and non-default address spaces
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Feb 16 09:29:54 PST 2016
And.. ignore me. I clearly hadn't read your email closely enough. This
is exactly what you were doing.
Philip
On 02/16/2016 09:27 AM, Philip Reames via llvm-dev wrote:
> 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
>
>
>
> _______________________________________________
> 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/b855d80f/attachment.html>
More information about the llvm-dev
mailing list