Artur Pilipenko via llvm-dev
2016-Feb-15 19:34 UTC
[llvm-dev] Masked intrinsics and non-default address spaces
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160215/3bd2328c/attachment.html>
Matt Arsenault via llvm-dev
2016-Feb-15 19:40 UTC
[llvm-dev] Masked intrinsics and non-default address spaces
On 02/15/2016 11:34 AM, Artur Pilipenko via llvm-dev wrote:> > 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: >+1. I don't particularly care about this set of intrinsics, but there are a handful of other memory intrinsics that currently suffer from the same problem of being arbitrarily restricted to addrspace(0). -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160215/21ddceed/attachment.html>
Mehdi Amini via llvm-dev
2016-Feb-15 20:55 UTC
[llvm-dev] Masked intrinsics and non-default address spaces
> On Feb 15, 2016, at 11:34 AM, Artur Pilipenko via llvm-dev <llvm-dev at lists.llvm.org> 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>) > >How would the "typeless" pointer interact with this? Would the problem be solved? (just curious) -- Mehdi> 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 <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/20160215/b54c5c78/attachment.html>
Hal Finkel via llvm-dev
2016-Feb-16 00:12 UTC
[llvm-dev] Masked intrinsics and non-default address spaces
----- Original Message -----> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Artur Pilipenko" <apilipenko at azulsystems.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, February 15, 2016 2:55:30 PM > Subject: Re: [llvm-dev] Masked intrinsics and non-default address > spaces> > On Feb 15, 2016, at 11:34 AM, Artur Pilipenko via llvm-dev < > > llvm-dev at lists.llvm.org > 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>) >> How would the "typeless" pointer interact with this? Would the > problem be solved? > (just curious)I'm under the impression that even typeless pointers will still have address spaces. Assuming I'm right about that, the proposed fix here makes sense to me. -Hal> -- > Mehdi> > 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-- -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
Philip Reames via llvm-dev
2016-Feb-16 17:27 UTC
[llvm-dev] Masked intrinsics and non-default address spaces
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>
Philip Reames via llvm-dev
2016-Feb-16 17:29 UTC
[llvm-dev] Masked intrinsics and non-default address spaces
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>
Possibly Parallel Threads
- Fwd: [PATCH] D17497: Support arbitrary address space for intrinsics
- LTO and intrinsics mangling
- Fwd: [PATCH] D17497: Support arbitrary address space for intrinsics
- Fwd: [PATCH] D17497: Support arbitrary address space for intrinsics
- LTO and intrinsics mangling