llvm dev - Jun 2009 - [LLVMdev] Regular Expressions

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

On Jun 15, 2009, at 11:33 AM, David Greene wrote:
> 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.
Why not synthesize the opcode string from the information passed down?

-Chris

On Monday 15 June 2009 14:35, Chris Lattner wrote:
> > 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.
>
> Why not synthesize the opcode string from the information passed down?
That's actually how I started things out initially.  The problem is that it 
leads to a less intuitive specification.  I'll see if I can illustrate.

Say we have a wrapper class like this:

class X86ValueType {
    ValueType VT;
    RegisterClass RegClass;
    string suffix;
}

Now we instantiate some concrete types:

class X86_f32 : X86ValueType {
  let VT = f32;
  let RegClass = FR32;
  let suffix = "ss";
}

class X86_v4f32 : X86ValueType {
  let VT = v4f32;
  let RegClass = VR128;
  let suffix = "ps";
}

class X86_v8f32 : X86ValueType {
  let VT = v8f32;
  let RegClass = VR256;
  let suffix = "ps";
}

Ok, you get the picture.  Now let's look at how we would write instruction 
patterns:

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blend", "blend",
"f32">;
defm BLENDPD  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0D, 
                  i32i8imm, "blend", "blend",
"f64">;

We have to send types as strings because we need to be able to munge them
for SSE vs. AVX.  Passing multiple types (v4f32, v8f32, etc.) is not
practical, it just obfuscates the top-level specification.

Now we need some guts:

multiclass sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<
  bits<8> opc,
  PatFrag ImmClass,
  string OpcodeString,
  string Intrinsic,
  string BaseType,
  list<list<dag>> ipatterns = [],
  string asm = ""
> {
  def rr_Int : ... 
  def rm_Int : ...
  def V#NAME#_128rrr_Int : fp_binary_vector_irrr<
    opc,
    // I'm not even sure this field reference will work
    !strconcat(OpcodeStr, 
               !cast<X86ValueType>(!strconcat("X86v??", 
                                              BaseType)).suffix,
    !strconcat(Intrinsic, 
               !strconcat("_", 
                         
!cast<X86ValueType>(!strconcat("X86v??",
                                                         BaseType)).suffix,
    cast<X86ValueType>(!strconcat("X86v??", BaseType)).VT,
    cast<X86ValueType>(!strconcat("X86v??", BaseType)).RegClass,
// Src
    cast<X86ValueType>(!strconcat("X86v??", BaseType)).RegClass,
// Dst
    [and probably some other stuff],
    ipatterns,
    asm
  > {
    let Prefix = TA;
    let HasOpSize = 1;
    let HasVEX = 1;
  }
  def V#NAME#_128rrm_Int : ...
  def V#NAME#_256rrr_Int : ... {
    let Prefix = TA;
    let HasOpSize = 1;
    let HasVEX = 1;
    let HasVEX_L = 1;
  }
  def V#NAME#_256rrm_Int : ...
}

Ok, that's the first level and right here we have a problem.  How do we
figure
out the vector length ("??" in the strings)?  We could pass it at the
top
level:

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blend", "blend",
"f32", 4>;

Now 4 is not the right vector length for VEX.L-encoded AVX, so we'll have to
munge it:

multiclass sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<
  bits<8> opc,
  PatFrag ImmClass,
  string OpcodeString,
  string Intrinsic,
  string BaseType,
  int BaseVL,
  list<list<dag>> ipatterns = [],
  string asm = ""
> {
  [...]
  def V#NAME#_256rrr_Int : fp_binary_vector_irrr<
    opc,
    // Not even sure this field reference will work
    !strconcat(OpcodeStr, 
               !cast<X86ValueType>(!strconcat(
                   // No support for cast to string yet, but not hard to add
                   // Need integer multiply support as well
                                   !strconcat("X86v",
cast<string>(2*BaseVL)),
                                              BaseType)).suffix,
    [...]
  > {
    let Prefix = TA;
    let HasOpSize = 1;
    let HasVEX = 1;
    let HasVEX_L = 1;
  }
  [...]
}

All right, we can make it work, but is it really worth the pain?  I'm really
concerned about making the top-level instruction specification .td as readable 
as possible, since that's what people will be primarily editing.

So which is more intuitive and less error-prone?  

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blend", "blend",
"f32", 4>;

or

defm BLENDPS  : sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, 
                  i32i8imm, "blendps", "blendps">;

(We can probably drop the Intrinsic string specification since in most cases
we can generate it from the opcode string).

Before answering, consider that the developer must understand how top-level 
parameters like type strings and vector lengths will be munged by the guts 
classes.  She needs to know this to know what values to pass for types and 
vector lengths.

The key problem is the differing type requirements for AVX vs. SSE.  There is
always some munging of some parameter required at some point.  Those 
parameters have to be strings since that's the only type in TableGen
flexible enough to have munging performed on it.  We could add lots of 
operators to munge other types but that would be needlessly complex and
expensive to implement.

Opcode strings are naturally strings.  They contain all of the typing 
information we need.  I think it is better to pass fewer arguments and
let TableGen do the hard work of figuring out the type requirements.

If you buy that argument, we have to have some way to match string patterns.
Regular expressions is a natural solution.

                               -Dave