search for: llvm_anyint_ty

...ype = { .u16, .u32, .u64, .s16, .s32, .s64 }; The presence of multiple types requires llvm.ptx.max to be overloaded for i16, i32 and i64. So I think that the right way to define the intrinsic would be (as in the attached max_not_working.patch file): def int_ptx_max : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, LLVMMatchType<0>], [Commutative]>; The problem is that the builtin is not recognised in the following test case: define ptx_device i16 @max_16(i16 %a, i16 %b) { entry: %d = call i16 @llvm.ptx.max(i16 %a,...

...ountered issues with overloading an intrinsic function. I have defined two types, abit (which is mapped, in Intrinsics.td, to i128) and qbit (accordingly mapped to i16). I would like my intrinsic function, CNOT(x,y), to accept either an abit or a qbit for each argument, so I overload with iAny and llvm_anyint_ty, as seemed to be the method for other intrinsics: def int_CNOT: Intrinsic<[], [llvm_anyint_ty, llvm_anyint_ty],[],["llvm.CNOT"]>; My llvm/clang directory builds successfully, but I get an error on getType from clang, which I believe is rooted in my llvm code. My question is simply...

...sues with overloading an intrinsic function. > > I have defined two types, abit (which is mapped, in Intrinsics.td, to i128) and qbit (accordingly mapped to i16). I would like my intrinsic function, CNOT(x,y), to accept either an abit or a qbit for each argument, so I overload with iAny and llvm_anyint_ty, as seemed to be the method for other intrinsics: > > def int_CNOT: Intrinsic<[], [llvm_anyint_ty, llvm_anyint_ty],[],["llvm.CNOT"]>; > > My llvm/clang directory builds successfully, but I get an error on getType from clang, which I believe is rooted in my llvm code....

...gt; param_types = []> { + string LLVMName = name; + bit isTarget = 0; + string TargetPrefix = ""; + list<LLVMType> RetTypes = []; + list<LLVMType> ParamTypes = param_types; + list<IntrinsicProperty> Properties = []; +} + +def iAny : ValueType<0, 254>; +def llvm_anyint_ty : LLVMType<iAny>; + +// Make sure we generate the long name without crashing +// CHECK: this_is_a_really_long_intrinsic_name_but_we_should_still_not_crash // llvm.this.is.a.really.long.intrinsic.name.but.we.should.still.not.crash +def int_foo : Intrinsic<"llvm.foo", [llvm_anyin...

I have a variadic intrinsic that is defined as something like this: def int_foobar : Intrinsic<[llvm_anyint_ty], [llvm_vararg_ty], [IntrNoMem, IntrSpeculatable]>; When I construct a call to the above intrinsic with IRBuilder::CreateIntrinsic, it mangles the intrinsic name with the return type (i64) and the actual argument types i32.i32. The...

Hi all, I'm proposing integer saturation intrinsics. def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; The first operand is the integer value being saturated, and second is the saturation bit position. For scalar integer types, the semantics are: int_ssat: x < -...

...0; >> + string TargetPrefix = ""; >> + list<LLVMType> RetTypes = []; >> + list<LLVMType> ParamTypes = param_types; >> + list<IntrinsicProperty> Properties = []; >> +} >> + >> +def iAny : ValueType<0, 254>; >> +def llvm_anyint_ty : LLVMType<iAny>; >> + >> +// Make sure we generate the long name without crashing >> +// CHECK: >> this_is_a_really_long_intrinsic_name_but_we_should_still_not_crash // >> llvm.this.is.a.really.long.intrinsic.name.but.we.should.still.not.crash >> +def in...

...g 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_anyfloat_ty,llvm_i32_ty,llvm_i32_ty],[IntrWriteMem],"llvm.migrate_end_float">;<br><br>I am not able to handle all of the pointer return type...

On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi all, > > I'm proposing integer saturation intrinsics. > > def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; > > The first operand is the integer value being saturated, and second is the saturation bit position. > > For scalar integer types, the semantics a...

...ng > 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<[llvm_anyfloat_ty,llvm_i32_ty,llvm_i32_ty], > [IntrWriteMem],"llvm.migrate_end_float">; > > I am not able to handle all of the pointer ret...

On Jun 17, 2011, at 3:42 PM, Eli Friedman wrote: > On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: >> Hi all, >> >> I'm proposing integer saturation intrinsics. >> >> def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; >> def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; >> >> The first operand is the integer value being saturated, and second is the saturation bit position. >> >> For scalar integer...

...u'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 and L...

...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 --------------------------------------------------------------------- Intel Israel (74) Limited T...

...t; On Jun 17, 2011, at 3:42 PM, Eli Friedman wrote: > >> On Fri, Jun 17, 2011 at 3:08 PM, Evan Cheng <evan.cheng at apple.com> wrote: >>> Hi all, >>> >>> I'm proposing integer saturation intrinsics. >>> >>> def int_ssat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; >>> def int_usat : Intrinsic<[llvm_anyint_ty], [LLVMMatchType<0>, llvm_i32_ty]>; >>> >>> The first operand is the integer value being saturated, and second is the saturation bit position. >>> >>> F...

...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 f...

...; 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 friends, and while it can make the IR look verbose at times, we...

...t or body 'help' to llvmdev-request at cs.uiuc.edu You can reach the person managing the list at llvmdev-owner at cs.uiuc.edu When replying, please edit your Subject line so it is more specific than "Re: Contents of LLVMdev digest..." Today's Topics: 1. llvm_anyint_ty clarification (Alberto Magni) 2. Re: How to make Polly ignore some non-affine memory accesses (Bernhard Reutner-Fischer) 3. Re: How to make Polly ignore some non-affine memory accesses (Tobias Grosser) 4. Re: How to make Polly ignore some non-affine memory acc...

I have defined the intrinsic as * def int_loop: Intrinsic<[],[llvm_i8_ty, llvm_empty_ty],[]>;* and also got the Codegen backend support in Instructioninfo.td file. Then created a .ll file to test it. The .ll file is like this *declare void @llvm.loop(i8, label)define void @fn() nounwind readnone {entry: ..... ..... call void @llvm.loop(i8 10, label %entry) ret void}* But

...t; LLVM IR intrinsics, in this case defined at > [LLVM_repo]/llvm/include/llvm/IR/IntrinsicsPowerPC.td, such as: > // Intrinsics used to generate ctr-based loops. These should only be > // generated by the PowerPC backend! > def int_ppc_mtctr : Intrinsic<[], [llvm_anyint_ty], []>; > def int_ppc_is_decremented_ctr_nonzero : Intrinsic<[llvm_i1_ty], [], []>; > > And these intrinsics are instantiated in the LLVM program, for example with the > following code in PPCCTRLoops.cpp: > IRBuilder<> CountBuilder(Preheader->getTe...

Hi, So, we currently have gc.result.int, gc.result.float. gc.result.ptr, gc.relocate, and gc.statepoint. gc.statepoint's signature is fine with a iPTRAny as the first argument. gc.result is in trouble, because none of the signatures admit even a simple array of integers, and there's no aAny. And certainly no vectors. So we can get a gc.result.vector to add to this mess, and admit [1] to