On Thursday 11 June 2009 12:28, Chris Lattner wrote:> On Jun 9, 2009, at 12:39 PM, David Greene wrote: > > On Tuesday 09 June 2009 14:34, Dan Gohman wrote: > >> Can you describe what problem you're trying to solve here? Does it > >> really need Regular Expressions? > > > > Yes. I want TableGen to be able to infer lots of stuff > > programmatically. > > This helps tremendously when specifying things like, oh, AVX. :) > > I don't see how this relates to regex's, and really don't want to suck > in an external regex library. Can you give an example of how this > would help?Sure: [Top-level specification] defm CVTSI2SS : sse1_avx_fp_cvt_scalar_xs_scalar64_xs_node_sintrinsic_rm< 0x2D, "cvtsi2ss", sint_to_fp, "cvtsi2ss", "f32", "i32">; [Meanwhile, down in the guts...] class fp_cvt_scalar_VXSnrr< // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr bits<8> opc, string OpcodeStr, SDNode OpNode, string DstType, string SrcType, int CustomPatterns = 0, list<dag> patterns = [], string asm = "">: fp_unary_vxs_n_rm_rr<opc, !cast<RegisterClass>(!patsubst("^f([0-9]+)","FR$1",!patsubst("^i([0-9]+)","GR$1",DstType))), [...] Basically, the code keys off type strings to deduce register classes and other such things. This makes specifying things like converts much easier because one doesn't need to pass a bunch of additional parameters around to specify register classes, etc. when it is entirely obvious what they should be given other parameters. I'm trying to reduce the number of classes/parameters to deal with so I can eventually get rid of the Perl script that's generating most of this stuff right now. This kind of pattern matching and substitution really helps simplify things to a point where I can imagine manually maintaining a smaller amount of information. The BSD regex library is very tiny, almost ideal for what we want to do, which is fill a functionality hole on Windows only. -Dave
On Jun 11, 2009, at 2:01 PM, David Greene wrote:> On Thursday 11 June 2009 12:28, Chris Lattner wrote: >>> >>> Yes. I want TableGen to be able to infer lots of stuff >>> programmatically. >>> This helps tremendously when specifying things like, oh, AVX. :) >> >> I don't see how this relates to regex's, and really don't want to >> suck >> in an external regex library. Can you give an example of how this >> would help? > > Sure: > > [Top-level specification] > defm CVTSI2SS : > sse1_avx_fp_cvt_scalar_xs_scalar64_xs_node_sintrinsic_rm< > 0x2D, "cvtsi2ss", sint_to_fp, "cvtsi2ss", "f32", "i32">; > > [Meanwhile, down in the guts...] > > class fp_cvt_scalar_VXSnrr< > // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr > bits<8> opc, > string OpcodeStr, > SDNode OpNode, > string DstType, > string SrcType, > int CustomPatterns = 0, > list<dag> patterns = [], > string asm = "" >> : fp_unary_vxs_n_rm_rr< > opc, > !cast<RegisterClass>(!patsubst("^f([0-9]+)","FR$1",! > patsubst("^i([0-9]+)","GR$1",DstType))), > [...]Very clever.> Basically, the code keys off type strings to deduce register classes > and > other such things. This makes specifying things like converts much > easier > because one doesn't need to pass a bunch of additional parameters > around to > specify register classes, etc. when it is entirely obvious what they > should be > given other parameters. > > I'm trying to reduce the number of classes/parameters to deal with > so I > can eventually get rid of the Perl script that's generating most of > this > stuff right now. This kind of pattern matching and substitution > really > helps simplify things to a point where I can imagine manually > maintaining > a smaller amount of information.Right, I definitely agree with your goal of reducing redundancy in the .td files! :) However, I don't see any reason to base this off of strings. Instead of passing down "f32" as a string, why not do something like this pseudo code: class X86ValueType { RegisterClass RegClass; ... } def X86_f32 : X86ValueType { let RegClass = FR32; ... }; def X86_i32 : X86ValueType { ... }; Then change fp_cvt_scalar_VXSnrr to be something like this:> class fp_cvt_scalar_VXSnrr< > // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr > bits<8> opc, > string OpcodeStr, > SDNode OpNode, > X86ValueType DstType, > X86ValueType SrcType, > int CustomPatterns = 0, > list<dag> patterns = [], > string asm = "" >> : fp_unary_vxs_n_rm_rr< > opc, DstType.RegClass,This lets you encode whatever you want as properties of the dependent class, makes everything "type safe", and eliminates string munging. Would something like this work? -Chris
Chris Lattner wrote:> However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 : X86ValueType { ... }; > > Then change fp_cvt_scalar_VXSnrr to be something like this: > >> class fp_cvt_scalar_VXSnrr< >> // Parent: avx_fp_cvt_scalar_xs_node_rm_DEF_V#NAME#_128rr >> bits<8> opc, >> string OpcodeStr, >> SDNode OpNode, >> X86ValueType DstType, >> X86ValueType SrcType, >> int CustomPatterns = 0, >> list<dag> patterns = [], >> string asm = "" >>> : fp_unary_vxs_n_rm_rr< >> opc, DstType.RegClass, > > This lets you encode whatever you want as properties of the dependent > class, makes everything "type safe", and eliminates string munging. > Would something like this work?Yes, that will work for this case and is probably a better solution than regular expressions. There are other cases where I want to key off opcode strings and there it's not practical to wrap each opcode in its own class. For example: !subst(SRCTYPE, !cast<ValueType>(!patsubst(".*ps$","v4f32",!patsubst(".*pd$","v2f64",OpcodeStr))), To reduce redundancy, developers must be able to write generic patterns like this: [(set DSTREGCLASS:$dst, // rr, rrr (xor (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src1))), (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src2)))))], The substitution then fills in the appropriate types, etc. based on which variant (32-bit, 64-bit, AVX, etc.) is being produced. I suppose you could argue that additional parameters specifying the source and dest types could be passed, but why bother when it is already encoded in the mnemonic? That would just be adding error-prone redundancy. In fact while writing this stuff this pattern matching and substitution already caught a few typing errors for us. -Dave