search for: llvm_float_ti

Hi Guys, I am trying to promote half to float for my intrinsic math operations, following class and pattern are defined. " class S_HF__HF< string asmstr> : Intrinsic <[llvm_float_ty ], [llvm_float_ty ], [IntrNoMem], !strconcat(asmstr, "_f16")>; def :Pat<( f16 (int_my_math_f16 f16:$src)), (F2Hsr (FEXTsr f16:$src) )>; “ where FEXTsr is

Tom, I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official "incubation" system whereby proposed backends could get a trial run before becoming part

In IntrinsicEmitter::EmitTypeGenerate, called from IntrinsicEmitter::EmitGenerator, here for (unsigned j = 0; j != N; ++j) { OS << " ArgTys.push_back("; EmitTypeGenerate(OS, ParamTys[j], ArgNo); OS << ");\n"; } I'm hitting this assertion: if (ArgType->isSubClassOf("LLVMMatchType")) { unsigned Number =

I have this intrinsic definition for llvm. def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], [llvm_anyfloat_ty, LLVMMatchType<0>]>; Can someone explain what LLVMMatchType does and how to specify it to match the first argument and not the return value? I've tried LLVMMatchType<1> but it fails in IntrinsicEmitter.cpp

That's a bug. I'm working on a fix.... On Apr 15, 2009, at 10:16 AM, Villmow, Micah wrote: > In IntrinsicEmitter::EmitTypeGenerate, called from > IntrinsicEmitter::EmitGenerator, here > for (unsigned j = 0; j != N; ++j) { > OS << " ArgTys.push_back("; > EmitTypeGenerate(OS, ParamTys[j], ArgNo); > OS << ");\n"; > }

Oops. That was premature. I think your original question was on the right track. TableGen distinguishes between known and "overloaded" types (like "llvm_anyfloat_ty" in your example). The overloaded types are numbered separately, and the argument to LLVMMatchType is an index into these overloaded types, ignoring the known types. So, in your case, the first

I still think there is a bug somewhere, but not sure where yet. This is what is generated in intrinsic.gen: case Intrinsic::opencl_math_fdistance: // llvm.opencl.math.fdistance ResultTy = Type::FloatTy; ArgTys.push_back(Tys[0]); ArgTys.push_back(Tys[0]); break; This is the intrinsic definition: def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty],

On Apr 15, 2009, at 9:29 AM, Villmow, Micah wrote: > I have this intrinsic definition for llvm. > def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], > [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > > Can someone explain what LLVMMatchType does and how to specify it > to match the first argument and not the return value?

Hi, I'm trying to create a Pattern that looks something like this: def my_inst : Instruction < let OutOperandList = (outs REG:$dst); let InOperandList = (ins imm:$src); let Uses = [R0]; > def int_my_intrinsic : Intrinsic < [llvm_float_ty], [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty], [] >; def : Pattern < (int_my_intrinsic imm:$a, imm:$b, imm:$c), [(set R0, (MOV_IMM

On Wed, Apr 15, 2009 at 11:15 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I still think there is a bug somewhere, but not sure where yet. > This is what is generated in intrinsic.gen: > case Intrinsic::opencl_math_fdistance:          // > llvm.opencl.math.fdistance >    ResultTy = Type::FloatTy; >    ArgTys.push_back(Tys[0]); >    ArgTys.push_back(Tys[0]);

On Apr 15, 2009, at 11:15 AM, Villmow, Micah wrote: > I still think there is a bug somewhere, but not sure where yet. > This is what is generated in intrinsic.gen: > case Intrinsic::opencl_math_fdistance: // > llvm.opencl.math.fdistance > ResultTy = Type::FloatTy; > ArgTys.push_back(Tys[0]); > ArgTys.push_back(Tys[0]); > break; OK. That looks right to me.

If I force it to use v2f32 for my register class, it still fails with: d:\hq\main\sw\appeng\tools\hpc\opencl\compiler\llvm\test\AMDIL>TableGen. exe -gen -dag-isel -I../../include/ test.td > output GPRV2F32:v2f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst, (i ntrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, GPRV2F32:v2f32:$src1)) TableGen.exe: In

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

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > 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

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