RFC: X86InstrFormats.td Refactoring

There is some redundancy at the instruction format level in the x86 .td files.
For example, in X86InstrFormats.td:

// SSE1 Instruction Templates:
//
// SSI - SSE1 instructions with XS prefix.

class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag>

      : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>;

// SSE3 Instruction Templates:
// S3SI - SSE3 instructions with XSrefix.

class S3SI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag>

      : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE3]>;

The only difference here is the parameter to Requires. There are many more
examples and this gets worse with AVX.

I'd like to propose a refactoring that looks something like this:

// SSE Instruction Templates:
//
// SSI - SSE Instructions with XS prefix

class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag>

      : I<o, F, outs, ins, asm, pattern>, XS;

/./ SSE1 Instruction Templates
//
// S1SI - SSE1 instructions with Xs prefix

class S1SI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag>

      : SSI<o, F, outs, ins, asm, pattern>, Requires<HasSSE1>;

This way we can reuse the SSI class and hide encoding details for many SSE
levels and AVX.

Sound good?

                                             -Dave

Actually, I meant to keep the existing class names intact to avoid global
changes. So what I'm proposing is actually:

class SSIb<bits<8> o, Format F, dag outs, dag ins, string asm,
   list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS;

class SSI<bits<8> o, Format F, dag outs, dag ins, string asm,
  list<dag> pattern>
       : SSIb<o, F, outs, ins, asm, pattern>, Requires<HasSSE1>;

                                           -Dave

There is some redundancy at the instruction format level in the x86 .td
files. For example, in X86InstrFormats.td:

// SSE1 Instruction Templates:
//
// SSI - SSE1 instructions with XS prefix.

class SSI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag>
>

     : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE1]>;

// SSE3 Instruction Templates:
// S3SI - SSE3 instructions with XSrefix.

class S3SI<bits<8> o, Format F, dag outs, dag ins, string asm, list<dag>
>

     : I<o, F, outs, ins, asm, pattern>, XS, Requires<[HasSSE3]>;

The only difference here is the parameter to Requires. There are many more
examples and this gets worse with AVX.

[...]

Actually, I meant to keep the existing class names intact to avoid global
changes. So what I'm proposing is actually:

class SSIb<bits<8> o, Format F, dag outs, dag ins, string asm,
  list<dag> pattern> : I<o, F, outs, ins, asm, pattern>, XS;

class SSI<bits<8> o, Format F, dag outs, dag ins, string asm,
list<dag> pattern>
      : SSIb<o, F, outs, ins, asm, pattern>, Requires<HasSSE1>;

Is this just factoring out the ", XS" part? As presented, it looks like
this change would introduce more redundancy that it would eliminate.

Dan

It's factoring out XS and the other encoding bits, but the real goal is to
separate out the Requires<> predicates. Doing this will help AVX quite a bit
as we'd like to build AVX format classes off of the existing ones. Most of
AVX simply recodes existing SSE instructions using the VEX prefix so it makes
sense to use the infrastructure already there. The problem is the Requires<>
parts are all inappropriate so we need to factor them out.

                                                        -Dave

Ok. I have no real objection to this. I look
forward to seeing how it helps in the context of
the rest of the changes :-).

Dan