similar to: Instruction selection pattern for intrinsic returning llvm_any_ty

> 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

Hi, On 03/30/2016 11:15 AM, Matt Arsenault wrote: > >> 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], >>

Hi, On 03/30/2016 11:38 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >> <mailto:mikael.holmen at ericsson.com>> wrote: >> >> i16 (divm16_pseudo …) >> >> stuff? >> >> I've tried >> (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) >> and >> ((i16, i16)

> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > Hi, > > On 03/30/2016 11:38 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>> <mailto:mikael.holmen at ericsson.com>> wrote: >>> >>> i16 (divm16_pseudo …) >>>

On 03/30/2016 11:51 AM, Matt Arsenault wrote: > >> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >> >> Hi, >> >> On 03/30/2016 11:38 AM, Matt Arsenault wrote: >>> >>>> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com >>>> <mailto:mikael.holmen at

> On Mar 30, 2016, at 11:58, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > > > On 03/30/2016 11:51 AM, Matt Arsenault wrote: >> >>> On Mar 30, 2016, at 11:43, Mikael Holmén <mikael.holmen at ericsson.com> wrote: >>> >>> Hi, >>> >>> On 03/30/2016 11:38 AM, Matt Arsenault wrote: >>>>

> On Mar 30, 2016, at 11:35, Mikael Holmén <mikael.holmen at ericsson.com> wrote: > > i16 (divm16_pseudo …) > > stuff? > > I've tried > (i16, i16 (divm16_pseudo i16:$src1, i16:$src2) > and > ((i16, i16) (divm16_pseudo i16:$src1, i16:$src2) > and a few other variants without managing to get it through. > > Thanks again, > Mikael Are you

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

It is my understanding that all you need to do is specify let isTarget = 1 in your .td file and it will generate target specific intrinsics. This should allow you to keep the IntrinsicsPTX.td file in the same location. Micah From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Monday, December 05, 2011 6:13 AM To: Alberto Magni Cc: Villmow, Micah; LLVM Developers Mailing List

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.

On Sun, Dec 4, 2011 at 1:10 PM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > 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

On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?

Dear all. I have a problem with the following situation: I want to handle an intrinsic function in a specific way. The prototype of my function is: "/int my_intrinsic_name()/" So I want to generate a move instruction which should use two register type operands: "/mov R1, R2/" For this purpose I assume that the instruction definition in the TargetInstrInfo.td file

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

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

Hello everyone, I am trying to implement the max PTX builtin function. This is defined in the following way: "max.type d, a, b;" where .type can be: .type = { .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

Hi! I'm not sure how to handle intrinsic functions that have non-i32 operands. The target only supports 32-bit registers natively but for some operations, only the lower 16 bits 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);

Hello, I was implementing the llvm_any_type in my intrinsic def int_csa_xxx : Intrinsic<[llvm_any_ty], [llvm_i32_ty]>; as the following in its corresponding builtins in Builtins.def: BUILTIN(__builtin_xxx, "v.", "nt") the "t" was sufficient here to not perform any type checking. The type checking was handled in CGBuiltin.cpp. This was working until

Have been running samba successfully authenticating to a windows 2003 domain since 3.0.1. Starting in 3.0.23 and 3.0.23b I can't do a "net ads join" on a HPUX itanium server running 11.23 ia64. I can kinit just fine w/ this userid. Samba was built with gcc 4.1.1. See below: root@serv00 # kinit jjurich_wa Password for jjurich_wa@DIVMS.UIOWA.EDU: root@serv00 #

Philip Reames wrote: >> 1. Introduce aAny. > > Having a generic any type seems fine. I assume you'd create something like > an llvm_any_type in Intrinsics.td? That's precisely what ifavpAny is about: integer, float, array, vector, pointer Any. aAny is meant for array-Any, and I wonder why so few people care about arrays. I'll go ahead with Any and llvm_any_type.