[LLVMdev] Enhancing TableGen

[Jakob Stoklund Olesen]

On Oct 7, 2011, at 11:23 AM, David A. Greene wrote:

> Evan Cheng <evan.cheng at apple.com> writes:
> 
>> Your proposed new TableGen functionalities are interesting but it is
>> clearly not where the code owners want it to go.
> 
> Jakob at least seems interested in the for loop stuff.  Am I reading you
> correctly, Jakob?  Having that feature would make a huge difference.

I think the for loops have merit, but not the way you want to use them.

Some target descriptions have many sequential definitions, for example PowerPC/PPCRegisterInfo.td:

// Vector registers
def V0  : VR< 0,  "v0">, DwarfRegNum<[77, 77]>;
def V1  : VR< 1,  "v1">, DwarfRegNum<[78, 78]>;
...
def V30 : VR<30, "v30">, DwarfRegNum<[107, 107]>;
def V31 : VR<31, "v31">, DwarfRegNum<[108, 108]>;

Such 'embarrassingly sequential' definitions have no value, and I would welcome a for-loop construct that can create them. I think this was the primary motivation behind Che-Liang's proposal.


I do NOT want to factor out redundancy from instruction definitions like this:

multiclass PTX_FLOAT_3OP<string opcstr> {
  def rr32 : InstPTX<(outs RegF32:$d),
                     (ins RndMode:$r, RegF32:$a, RegF32:$b),
                     !strconcat(opcstr, "$r.f32\t$d, $a, $b"), []>;
  def ri32 : InstPTX<(outs RegF32:$d),
                     (ins RndMode:$r, RegF32:$a, f32imm:$b),
                     !strconcat(opcstr, "$r.f32\t$d, $a, $b"), []>;
  def rr64 : InstPTX<(outs RegF64:$d),
                     (ins RndMode:$r, RegF64:$a, RegF64:$b),
                     !strconcat(opcstr, "$r.f64\t$d, $a, $b"), []>;
  def ri64 : InstPTX<(outs RegF64:$d),
                     (ins RndMode:$r, RegF64:$a, f64imm:$b),
                     !strconcat(opcstr, "$r.f64\t$d, $a, $b"), []>;
}

As repeated many times on this thread, the most common operation that a .td file must support is looking up an instruction and figuring out what its properties are and where they came from.

Adding further abstractions to factor out redundancy works against that.

Instruction definitions are hard enough to read as is. The direction you are going would make it much worse.

/jakob