search for: intrinsicinfo

From: Villmow, Micah Sent: Tuesday, November 06, 2012 1:37 PM To: 'llvm-dev at cs.uiuc.edu' Cc: Guo, Xiaoyi Subject: Bug in SelectionDAG visitTargetIntrinsic We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different

...unsigned Intrinsic) { - bool HasChain = !I.doesNotAccessMemory(); - bool OnlyLoad = HasChain && I.onlyReadsMemory(); + unsigned Intrinsic) { + // Info is set by getTgtMemInstrinsic + TargetLowering::IntrinsicInfo Info; + bool IsTgtIntrinsic = TLI.getTgtMemIntrinsic(Info, I, Intrinsic); + bool HasChain = Info.readMem || Info.writeMem; + bool OnlyLoad = HasChain && Info.readMem; This doesn't seem right. If a call is marked ReadNone, it doesn't seem legal to select it to an intrinsic that r...

...(opcode.Text, " $dst, $src, $src2, $src3"), [(set GPRV2F32:$dst, (intr GPRV2F32:$src, GPRV2F32:$src2, GPRV2F32:$src3))]>; ... } Now, this doesn't completely work, because LLVM does not allow overloading of intrinsics values, so there needs to be a little coding in *IntrinsicInfo class. AMD always encodes builtin names as __amdil_mad_f32, __amdil_mad_v2f32, __amdil_mad_v4f32, etc.... So in the function "*IntrinsicInfo::lookup_name", when attempting to find out what intrinsic the function maps to, the AMDIL backend strips off the type, and then looks up for just ...

...; > [(set GPRV2F32:$dst, > > (intr GPRV2F32:$src, GPRV2F32:$src2, GPRV2F32:$src3))]>; > > ... > > } > > > > Now, this doesn't completely work, because LLVM does not allow overloading of intrinsics values, so there needs to be a little coding in *IntrinsicInfo class. > > AMD always encodes builtin names as __amdil_mad_f32, __amdil_mad_v2f32, __amdil_mad_v4f32, etc.... > > So in the function "*IntrinsicInfo::lookup_name", when attempting to find out what intrinsic the function maps to, the AMDIL backend strips off the type, and then...

...$src, $src2, $src3"), >      [(set GPRV2F32:$dst, >          (intr GPRV2F32:$src, GPRV2F32:$src2, GPRV2F32:$src3))]>; > ... > } > > Now, this doesn't completely work, because LLVM does not allow overloading of intrinsics values, so there needs to be a little coding in *IntrinsicInfo class. > AMD always encodes builtin names as __amdil_mad_f32, __amdil_mad_v2f32, __amdil_mad_v4f32, etc.... > So in the function "*IntrinsicInfo::lookup_name", when attempting to find out what intrinsic the function maps to, the AMDIL backend strips off the type, and then looks up f...

...2:$dst, > > > (intr GPRV2F32:$src, GPRV2F32:$src2, GPRV2F32:$src3))]>; > > > ... > > > } > > > > > > Now, this doesn't completely work, because LLVM does not allow overloading of intrinsics values, so there needs to be a little coding in *IntrinsicInfo class. > > > AMD always encodes builtin names as __amdil_mad_f32, __amdil_mad_v2f32, __amdil_mad_v4f32, etc.... > > > So in the function "*IntrinsicInfo::lookup_name", when attempting to find out what intrinsic the function maps to, the AMDIL backend strips off the type,...

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. Also I don't know yet how to make llvm recognize the intrinsics defined in lib/Target/PTX/PTXIntrinsics.td, the only other backend that does so is MBlaze. A tentative patch is attached. Bye, Alb...

...gt;> 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 included by PTXIntrinsicInfo.cpp. This is a quite big modification, do you agree with this ? Or do you have a better solution. I'm opposed to this, mainly because we need the intrinsic definitions to be defined during LLVM IR optimization and not just at code-gen time. This is particularly important for pure intrinsics,...

...t; 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. > I'm opposed to this, mainly because we need the intrinsic definitions to be defined during LLVM IR optimization and not just at code-gen time. This is particularly important for pu...

...y 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? How do we then get at the generated files in the PTXIntrinsicInfo class in the back-end? What exactly does isTarget do? It seems to remove a lot of the intrinsic information in the Intrinsics.gen file, but I can't find any documentation on it. > **** > > ** ** > > Micah**** > > ** ** > > *From:* Justin Holewinski [mailto:justin....

On Mon, Nov 21, 2011 at 5:31 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <alberto.magni86 at gmail.com> > wrote: >> >> On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski >> <justin.holewinski at gmail.com> wrote: >> > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni >> >

On Mon, Nov 21, 2011 at 11:45 AM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > On Mon, Nov 21, 2011 at 3:36 PM, Justin Holewinski > <justin.holewinski at gmail.com> wrote: > > On Mon, Nov 21, 2011 at 7:01 AM, Alberto Magni < > alberto.magni86 at gmail.com> > > wrote: > >> > >> Hi Justin, > >> > >> attached you find

...et/AMDGPU/AMDILISelLowering.h > llvm/trunk/lib/Target/AMDGPU/AMDILInstrInfo.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILInstrInfo.h > llvm/trunk/lib/Target/AMDGPU/AMDILInstrInfo.td > llvm/trunk/lib/Target/AMDGPU/AMDILInstructions.td > llvm/trunk/lib/Target/AMDGPU/AMDILIntrinsicInfo.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILIntrinsicInfo.h > llvm/trunk/lib/Target/AMDGPU/AMDILIntrinsics.td > llvm/trunk/lib/Target/AMDGPU/AMDILMultiClass.td > llvm/trunk/lib/Target/AMDGPU/AMDILNIDevice.cpp > llvm/trunk/lib/Target/AMDGPU/AMDILNIDevice.h > llv...