I've got another idea for a tblgen extension but I don't have a good feel for how feasible it is. Hopefully someone can provide guidance. What I want to do is something like this: class C1<int A, string B> { int foo = A; string bar = B; } class Bb<int A> : C1<A, "foo">; class Cb<int A> : C1<A, "bar">; class C2<C1 Base, int A> : Base<A>; def I1 : C2<Bb, 1>; def I2 : C2<Cb, 2>; and this: class Z<int A> { int moo = A; } class Z1 : Z<1>; class Z2 : Z<2>; multiclass C2<int A, string B, Z ZZ> { def D1 : Bb<A>, ZZ; def D2 : Cb<A>, ZZ; } defm D3 : C2<1, Z1>; defm D4 : C2<2, Z2>; Right now tblgen doesn't understand class name arguments like this as it expects to resolve subclasses immediately. Being able to resolve subclasses lazily would open up a whole lot of opportunity to reduce redundancy in .td files. My sense is to implement this we'd need something like a ClassInit (analogous to a VarInit) and a call to resolve references at the right time. But I don't know how deeply coded subclasses are in tblgen. Are things going to break spectacularly if subclass information isn't available immediately? Anyone have a sense of the amount of work to add a feature like this? -Dave
Can you give an example of where you would use such a feature? It seems entirely too abstract (at least to me) at the moment. On Tue, Apr 7, 2009 at 1:11 AM, David Greene <dag at cray.com> wrote:> I've got another idea for a tblgen extension but I don't have a good feel > for > how feasible it is. Hopefully someone can provide guidance. > > What I want to do is something like this: > > class C1<int A, string B> { > int foo = A; > string bar = B; > } > > class Bb<int A> : C1<A, "foo">; > class Cb<int A> : C1<A, "bar">; > > class C2<C1 Base, int A> : Base<A>; > > def I1 : C2<Bb, 1>; > def I2 : C2<Cb, 2>; > > and this: > > class Z<int A> { > int moo = A; > } > > class Z1 : Z<1>; > class Z2 : Z<2>; > > multiclass C2<int A, string B, Z ZZ> { > def D1 : Bb<A>, ZZ; > def D2 : Cb<A>, ZZ; > } > > defm D3 : C2<1, Z1>; > defm D4 : C2<2, Z2>; > > Right now tblgen doesn't understand class name arguments like this as it > expects to resolve subclasses immediately. Being able to resolve > subclasses > lazily would open up a whole lot of opportunity to reduce redundancy in .td > files. > > My sense is to implement this we'd need something like a ClassInit > (analogous > to a VarInit) and a call to resolve references at the right time. But I > don't > know how deeply coded subclasses are in tblgen. Are things going to break > spectacularly if subclass information isn't available immediately? > > Anyone have a sense of the amount of work to add a feature like this? > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090407/3b88156f/attachment.html>
On Tuesday 07 April 2009 01:18, someguy wrote:> Can you give an example of where you would use such a feature? > It seems entirely too abstract (at least to me) at the moment.Basically I wanted to pass the various prefix encoding classes (XS, XD, etc.) down into generic SIMD multiclasses so that we could write rr / rm patterns once and reuse them with different prefix encoding base classes for the various x86 SIMD instruction sets. These prefix bits are reused in AVX and I found myself duplicating all of the SIMD boilerplate for AVX that already exists for SSE simply because the prefix encoding classes are hard-coded into the SSE classes. The way I'm going to do this is define some global prefix bits<> and pass those instead. I'll use these just for AVX initially but we can move SSE over to them and share code going forward. -Dave