search for: anyint

...for this approach. Such an intrinsic was actually also proposed in Sam's original RFC (see https://lists.llvm.org/pipermail/llvm-dev/2019-May/132512.html), but we hadn't implemented it yet. This intrinsic will probably look something like this: <N x i1> @llvm.loop.get.active.mask(AnyInt, AnyInt) It produces a <N x i1> predicate based on its two arguments, the number of elements and the vector trip count, and it will be used by the predicated masked loads/stores instructions in the vector body. I will start drafting an implementation for this and continue with this in D79100...

...ics.td file. Do we need to create a number of intrinsics with different return types? If so i want to know the set of types which collectively encompass all the possibilities posed by the instruction type I would for example try to map all dependencies via overloading to three intrinsic types: anyint,anyfloat and ptr_ty. Would that be sufficient or is there any simpler approach to this? As far as i understand void_ty means "no return value" and not the C semantics of void. The strong type system makes me fear that this approach won't work either? Thank You Aditya _...

...32_ty,llvm_vararg_ty],[IntrWriteMem],"llvm.migrate_begin">;<br> <br>I want to replace the instructions from this set , having outgoing data dependencies, with " migrate_end " intrinsic instructions.<br>I created two migrate_end intrinsics with return types anyint(iAny Value Type) and any float(fAny Value Type).<br>Entries in the Intrinsics.td file:<br>def int_migrate_end_int : Intrinsic<[llvm_anyint_ty,llvm_i32_ty,llvm_i32_ty],[IntrWriteMem],"llvm.migrate_end_int">;<br>def int_migrate_end_float : Intrinsic<[llvm_anyflo...

..._i32_ty,llvm_vararg_ty], > [IntrWriteMem],"llvm.migrate_begin">; > > I want to replace the instructions from this set , having outgoing > data dependencies, with " migrate_end " intrinsic instructions. > I created two migrate_end intrinsics with return types anyint(iAny > Value Type) and any float(fAny Value Type). > Entries in the Intrinsics.td file: > def int_migrate_end_int : > Intrinsic<[llvm_anyint_ty,llvm_i32_ty,llvm_i32_ty], > [IntrWriteMem],"llvm.migrate_end_int">; > def int_migrate_end_float : > Intrinsic&...

...for this approach. Such an intrinsic was actually also proposed in Sam's original RFC (see https://lists.llvm.org/pipermail/llvm-dev/2019-May/132512.html), but we hadn't implemented it yet. This intrinsic will probably look something like this: <N x i1> @llvm.loop.get.active.mask(AnyInt, AnyInt) It produces a <N x i1> predicate based on its two arguments, the number of elements and the vector trip count, and it will be used by the predicated masked loads/stores instructions in the vector body. I will start drafting an implementation for this and continue with this in D79100...

...;ll need to add lib/VMCore/AutoUpgrade.cpp support for this change, because we need to be able to read old .bc and .ll files that use the previous form of the intrinsic. -Chris > > This patch updates the type of the second parameter of memset in > Intrinsics.td, from llvm_i8_ty, to llvm_anyint_ty: > > def int_memset : Intrinsic<[], > - [llvm_anyptr_ty, llvm_i8_ty, llvm_anyint_ty, > + [llvm_anyptr_ty, llvm_anyint_ty, llvm_anyint_ty, > llvm_i32_ty, llvm_i1_ty], > > IRBuilder.cpp an...

Hi Eli, > The problem with your proposal, as written, is that the vectorizer is producing the intrinsic. Because we don’t impose any ordering on optimizations before codegen, every optimization pass in LLVM would have to be taught to preserve any @llvm.set.loop.elements.i32 whenever it makes any change. This is completely impractical because the intrinsic isn’t related to anything