search for: llvm_i16_ty

Hi, If I define a intrinsic function with pointer-typed parameter, for example, def llvm_foo_ptr_ty : LLVMPointerType<llvm_i16_ty>; def int_foo_get : Intrinsic<[llvm_foo_ptr_ty], [llvm_foo_ptr_ty, llvm_i32_ty], [IntrReadArgMem]>; How to lower it for the backend? I'm not sure what kind of register (i16 or i32 or i32) is needed in this case? If the parameter is LLVMPointerType<llvm_i32_ty> instead of LLVMPoi...

Hi, On my out-of-tree target I have an intrinsic def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], [llvm_i16_ty, llvm_i16_ty], [IntrNoMem]>; that I want to translate to the following instruction during instruction selection: def divm16_pseudo : MyPseudoInst< (outs aNh_0_7:$dst, aNh_0_7:$dst2), (ins aNh_0_7:$src1, aNh_0_7:$src2)>; So I've done a pat...

...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, i16 %b) ret i16 %d } declare i16 @llvm.ptx.max(i16, i16) Things change if I define explicitly the i16 intrinsic, like this: def int_ptx_max : Intrinsic<[llvm_i16_ty], [llvm_i16_ty, llvm_i16_ty], [Commutative]>; In this case all goes well. But this is obviously non-extensible. Am I using the llvm_anyint_ty type in the right way ? Is there another way to implement this kind of behaviour? Thanks, Alber...

> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > On my out-of-tree target I have an intrinsic > > def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], > [llvm_i16_ty, llvm_i16_ty], > [IntrNoMem]>; > > that I want to translate to the following instruction during instruction selection: > > def divm16_pseudo : MyPseudoInst< > (outs aNh_0_7:$dst, aNh_0_7:$dst2), > (ins aNh_0_7:$src1, aNh_0_7:$src2)&...

...s are significant. For example, the SMULS instruction does a 16 x 16 fractional multiply with saturation. I've defined an intrinsic function: int __builtin_opus_smuls(short a, short b); def int_opus_smuls : GCCBuiltin<"__builtin_opus_smuls">,     Intrinsic<[llvm_i32_ty], [llvm_i16_ty, llvm_i16_ty],     [IntrNoMem]>; ; ModuleID = 'test.c' target datalayout = "E-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-n32" target triple = "opus-octasic-unknownos" @a = common global i16 0, align 2 @b = common global i16 0, align...

....cpp is only a partial solution, with the problems mentioned above. In my mind, the cleanest solution would be to just write out explicit intrinsics for each possible type. We can still use multiclasses to an extent: multiclass PTXBinaryIntrinsic<string prefix> { def _u16 : Intrinsic<[llvm_i16_ty], [llvm_i16_ty, llvm_i16_ty], [InstrNoMem]>, GCCBuiltin<!strconcat(prefix, "_u16")>; // Repeat for s16, u32, s32, u64, s64, f32, f64 } defm int_ptx_mad<"__builtin_ptx_mad">; It's not the cleanest, but it gets the job done (unless I'm missi...

....cpp is only a partial solution, with the problems mentioned above. In my mind, the cleanest solution would be to just write out explicit intrinsics for each possible type. We can still use multiclasses to an extent: multiclass PTXBinaryIntrinsic<string prefix> { def _u16 : Intrinsic<[llvm_i16_ty], [llvm_i16_ty, llvm_i16_ty], [InstrNoMem]>, GCCBuiltin<!strconcat(prefix, "_u16")>; // Repeat for s16, u32, s32, u64, s64, f32, f64 } defm int_ptx_mad<"__builtin_ptx_mad">; It's not the cleanest, but it gets the job done (unless I'm missi...

...ntioned above. In my mind, the > cleanest solution would be to just write out explicit intrinsics for each > possible type. We can still use multiclasses to an extent:**** > > ** ** > > multiclass PTXBinaryIntrinsic<string prefix> {**** > > def _u16 : Intrinsic<[llvm_i16_ty], [llvm_i16_ty, llvm_i16_ty], > [InstrNoMem]>,**** > > GCCBuiltin<!strconcat(prefix, "_u16")>;**** > > // Repeat for s16, u32, s32, u64, s64, f32, f64**** > > }**** > > ** ** > > defm int_ptx_mad<"__builtin_ptx_mad">...

...;0x2, "mov">;* *def : TargetPat<(int_myintrinsicname), (MOVInstr)>;* /// error: In anonymous.4: Instruction 'MOVInstr' expects more operands than were provided./ int the corresponding /inclue/llvm/IR/IntrinsicsTarget.td/ file: *def int_myintrinsicname : Intrinsic< [llvm_i16_ty], [], [<IntrinsicProperty>], "llvm.my_intrinsic_name" >;* This causes an error (shown in a comment) because I have specified an instruction class which has two operands (one in "outs" list and the other one in "ins" list, but pattern knows that the SRC has on...

...t;> On Mar 30, 2016, at 09:33, Mikael Holmén via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> On my out-of-tree target I have an intrinsic >> >> def int_phx_divm_u16 : Intrinsic<[llvm_any_ty], >> [llvm_i16_ty, llvm_i16_ty], >> [IntrNoMem]>; >> >> that I want to translate to the following instruction during instruction selection: >> >> def divm16_pseudo : MyPseudoInst< >> (outs aNh_0_7:$dst, aNh_0_7:$dst2), >> (ins a...

Hi Justin, sorry for the delay, I have been busy. Micah's proposal requires to move the definitions of the intrinsics from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td thus allowing the generation of the file PTXGenIntrinsics.inc which will be included by PTXIntrinsicInfo.cpp. This is a quite big modification, do you agree with this ? Or do you have a better solution.

...llvm_v16i1_ty], > [IntrNoMem]>; But other intrinsics expect a i8/i16 as the mask operand: > def int_x86_avx512_gather_dps_mask_512 : >GCCBuiltin<"__builtin_ia32_mask_gatherdps512">, > Intrinsic<[llvm_v16f32_ty], [llvm_v16f32_ty, llvm_i16_ty, > llvm_v16i32_ty, llvm_ptr_ty, llvm_i32_ty], > [IntrReadMem]>; I expected a v8i1/v16i1 for the gather intrinsics. Is there a reason for this type difference or is it just an oversight? This is the case for the compare, gather, scatter, and blend int...

...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, i16 %b) ret i16 %d } declare i16 @llvm.ptx.max(i16, i16) Things change if I define explicitly the i16 intrinsic, like this: def int_ptx_max : Intrinsic<[llvm_i16_ty], [llvm_i16_ty, llvm_i16_ty], [Commutative]>; In this case all goes well. But this is obviously non-extensible. Am I using the llvm_anyint_ty type in the right way ? Is there another way to implement this kind of behaviour? Thanks, Alber...

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

...i8** +def llvm_empty_ty : LLVMEmptyStructType; // { } +def llvm_descriptor_ty : LLVMPointerType<llvm_empty_ty>; // { }* def llvm_v16i8_ty : LLVMPackedType<v16i8,16, llvm_i8_ty>; // 16 x i8 def llvm_v8i16_ty : LLVMPackedType<v8i16, 8, llvm_i16_ty>; // 8 x i16 @@ -121,10 +131,10 @@ //===--------------- Variable Argument Handling Intrinsics ----------------===// // -def int_vastart : Intrinsic<[llvm_void_ty, llvm_ptrptr_ty], [], "llvm.va_start">; -def int_vacopy : Intrinsic<[llvm_void_ty, llvm_ptrptr_ty, llvm_p...

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

...], > [IntrNoMem]>; > - def int_x86_sse42_crc32_16 : GCCBuiltin<"__builtin_ia32_crc32hi">, > + def int_x86_sse42_crc32_32_16 : GCCBuiltin<"__builtin_ia32_crc32hi">, > Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i16_ty], > [IntrNoMem]>; > - def int_x86_sse42_crc32_32 : GCCBuiltin<"__builtin_ia32_crc32si">, > + def int_x86_sse42_crc32_32_32 : GCCBuiltin<"__builtin_ia32_crc32si">, > Intrinsic<[llvm_i32_ty], [llvm_i32_ty,...