search for: llvm_anyvector_ty

...4, <16 x i1> %mask) 6 types x 3 vector sizes = 18 names for one operation I propose to remove name mangling from these intrinsics: %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x i32>%passthru, i32 4, <16 x i1> %mask) def int_masked_load : Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, NoNameMangling]>; // new property It will significantly simplify reading and manual writing. What do you think? Thank you. - Elena ---------------------------------------------...

...;>> >>> I propose to remove name mangling from these intrinsics: >>> %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x >>> i32>%passthru, i32 4, <16 x i1> %mask) >>> >>> def int_masked_load : >>> Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, >>> llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, >>> NoNameMangling]>; >>> // new property >>> >>> It will significantly simplify reading and manual writing. >>> What do you think? >> >...

...types x 3 vector sizes = 18 names for one operation > > I propose to remove name mangling from these intrinsics: > %res = call <16 x i32> @llvm.masked.load (i32* %addr, <16 x > i32>%passthru, i32 4, <16 x i1> %mask) > > def int_masked_load : > Intrinsic<[llvm_anyvector_ty], [llvm_anyptr_ty, llvm_anyvector_ty, > llvm_anyint_ty, llvm_anyvector_ty], [IntrReadArgMem, NoNameMangling]>; > // new property > > It will significantly simplify reading and manual writing. > What do you think? We already have this kind of situation for @llvm.memcpy and frie...

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

My gut feeling is that it’s not worth it. When we move from typed to untyped pointers, we’re going to change the mangling from something like p200i8 to just p200, which is already quite a bit cleaner, and actually looks cleaner to me than the version proposed in this patch. David > On 24 Feb 2016, at 17:28, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This

...is to specify a pointer of certain type > in any address space, but it seems never care about the type. What makes it > worse is that, since the verifier is not checking its type, many intrinsics > actually has the wrong type definition. For example, int_aarch_neon_st2 is > defined as (llvm_anyvector_ty, LLVMMatchType<0>, > LLVMAnyPointerType<LLVMMatchType<0>>), but in reality, it has type like > (v8i8, v8i8, i8*) instead of (v8i8, v8i8, v8i8*). I write up a patch myself > to check all types in LLVMAnyPointerType and many regression tests failed. > I cannot find a way...

This probably needs broader discussion. We have an existing naming mechanism for polymorphic intrinsics; Elena is proposing a new one to avoid making the names for various load/store intrinsics particularly ugly. My personal take: 1) I like the cleaner naming scheme. 2) I'm not sure the additional complexity is worth it. (Not specific to the particular implementation proposed here.) 3) I

> On Sep 19, 2014, at 9:57 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > So the proposal is that during development new features are added to > test/Features/compatibility.ll (or some other name). When 3.6 is > released, we will > > * assemble the file with llvm-as-3.6. > * Check in the .bc file as test/Features/Input/compatibility-3.6.bc > *