[LLVMdev] Regular Expressions

David Greene dag at cray.com
Mon Jun 15 11:33:57 PDT 2009

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:


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.


More information about the llvm-dev mailing list