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 argument is the first overloaded type, so you should use LLVMMatchType<0> to refer to it. On Apr 15, 2009, at 10:31 AM, Bob Wilson wrote:> 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"; >> } >> I'm hitting this assertion: >> if (ArgType->isSubClassOf("LLVMMatchType")) { >> unsigned Number = ArgType->getValueAsInt("Number"); >> assert(Number < ArgNo && "Invalid matching number!"); >> >> Where both Number and ArgNo are 1. >> >> -----Original Message----- >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- >> bounces at cs.uiuc.edu] >> On Behalf Of Bob Wilson >> Sent: Wednesday, April 15, 2009 9:53 AM >> To: LLVM Developers Mailing List >> Subject: Re: [LLVMdev] Tablegen question >> >> >> 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? >>> >>> I've tried LLVMMatchType<1> but it fails in IntrinsicEmitter.cpp >> >> Can you give some more info about how LLVMMatchType<1> fails? That >> should do what you want. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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],
[llvm_anyfloat_ty, LLVMMatchType<0>]>;
The problem comes when I try to use the intrinsic. It gives me the
following error:
GPRV2F32:f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst,
(intrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0,
GPRV2F32:f32:$src1))
TableGen.exe: In MACRO_DISTANCE_FAST_v2f32: Type inference contradiction
found in node!
I'm using the following test td file.
This is generated with putting it in include and running the command
Tablegen.exe -dag-isel -I. test.td
The pattern in question is:
ILFormat<(outs Dst:$dst), (ins Src:$src0, Src:$src1),
",($dst),($src0, $src1)",
[(set Dst:$dst, (OpNode Src:$src0, Src:$src1))]
As the intrinsic specifies, the two source register classes should be
the same, however, Tablegen is somehow interpreting that it should be
f32 instead of v2f32.
Any help would be greatly appreciated,
Micah
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Bob Wilson
Sent: Wednesday, April 15, 2009 10:37 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Tablegen question
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 argument is the first overloaded type, so you should
use LLVMMatchType<0> to refer to it.
On Apr 15, 2009, at 10:31 AM, Bob Wilson wrote:
> 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";
>> }
>> I'm hitting this assertion:
>> if (ArgType->isSubClassOf("LLVMMatchType")) {
>> unsigned Number = ArgType->getValueAsInt("Number");
>> assert(Number < ArgNo && "Invalid matching
number!");
>>
>> Where both Number and ArgNo are 1.
>>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-
>> bounces at cs.uiuc.edu]
>> On Behalf Of Bob Wilson
>> Sent: Wednesday, April 15, 2009 9:53 AM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Tablegen question
>>
>>
>> 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?
>>>
>>> I've tried LLVMMatchType<1> but it fails in
IntrinsicEmitter.cpp
>>
>> Can you give some more info about how LLVMMatchType<1> fails?
That
>> should do what you want.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.td
Type: application/octet-stream
Size: 3062 bytes
Desc: test.td
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090415/2696ce6d/attachment.obj>
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]); > break; > > This is the intrinsic definition: > def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], > [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > The problem comes when I try to use the intrinsic. It gives me the > following error: > GPRV2F32:f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst, > (intrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, > GPRV2F32:f32:$src1)) > TableGen.exe: In MACRO_DISTANCE_FAST_v2f32: Type inference contradiction > found in node! > > I'm using the following test td file. > > This is generated with putting it in include and running the command > Tablegen.exe -dag-isel -I. test.td > > > The pattern in question is: > ILFormat<(outs Dst:$dst), (ins Src:$src0, Src:$src1), > ",($dst),($src0, $src1)", > [(set Dst:$dst, (OpNode Src:$src0, Src:$src1))] > > As the intrinsic specifies, the two source register classes should be > the same, however, Tablegen is somehow interpreting that it should be > f32 instead of v2f32. >The intrinsic definition says that the second source's type should match the return value's type, which it is. Can you come up with a small testcase .td file that shows how LLVMMatchType<1> fails here? -bw
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.> This is the intrinsic definition: > def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], > [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > The problem comes when I try to use the intrinsic. It gives me the > following error: > GPRV2F32:f32:$src1 MACRO_DISTANCE_FAST_v2f32: (set GPRF32:f32:$dst, > (intrinsic_w_chain:f32 84:iPTR, GPRV2F32:v2f32:$src0, > GPRV2F32:f32:$src1)) > TableGen.exe: In MACRO_DISTANCE_FAST_v2f32: Type inference > contradiction > found in node!Your "$src1" is f32 instead of v2f32. I've run into some problems like this before and concluded that TableGen's type inference is awesome but still doesn't do everything one might want it to do. In this case, I think you ought to just specify the types explicitly. You're specifying the register classes, but a register class can hold multiple types. It looks like your GPRV2F32 register class must also allow f32 types -- or else something else weird is happening.