[LLVMdev] Enhancing TableGen

[Che-Liang Chiou]

Hi Jakob and David,

The for-loop inside multiclass definition does not have to add extra
abstraction layer. As in the pseudo codes that David wrote earlier
(see below), it only condenses the repetitive 'def' statements inside
the multiclass definition into a more compact and less copy-paste
style form, instead of encapsulating them somewhere outside the
multiclass definition. I believe this would be more readable and
easier to maintain than the repetitive copy-n-paste 'def' statements
as in the PTXInstInfo.td.

I understand if you don't want an extra layer of abstraction (which
adds extra looking-ups to someone reading td files), but I think we
can have for-loop inside a multiclass without abstractions.

--------------------
multiclass sse_binop<opcode> {
 for type = [f32, f64, v4f32, v2f64]
     regclass = [FP32, FP64, VR128, VR128]
     suffix = [ss, sd, ps, pd] {

   def !toupper(suffix)#rr : Instr<
     [(set (type regclass:$dst), (type (opcode (type regclass:$src1),
                                               (type regclass:$src2))))]>;
   def !toupper(suffix)#rm : Instr<
     [(set (type regclass:$dst), (type (opcode (type regclass:$src1),
                                               (type addr:$src2))))]>;
 }
}
--------------------

Regards,
Che-Liang

On Sat, Oct 8, 2011 at 7:24 AM, Jakob Stoklund Olesen <jolesen at apple.com> wrote:
>
> On Oct 7, 2011, at 2:23 PM, David A. Greene wrote:
>
>>> 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.
>>
>> Ok.  What properties are most important to look up?  I have found it
>> really easy to just run "tblgen X86.td" and look at the output.  That's
>> really the canonical definition, right?
>
> In other words, .td files are write-only.  This is not acceptable.
>
> It also doesn't answer '...and where they came from'.
>
>> This could be mitigated somewhat by doing something like this:
>>
>> class binary_pattern<string opcstr, string type> {
>>  string pattern = !strconcat(opcstr, "$r."#type#"\t$d, $a, $b");
>> }
>>
>> multiclass PTX_FLOAT_3OP<string opcstr> {
>>  def rr32 : InstPTX<(outs RegF32:$d),
>>                     (ins RndMode:$r, RegF32:$a, RegF32:$b),
>>                     binary_pattern<opcstrm "f32">.pattern, []>;
>>  def ri32 : InstPTX<(outs RegF32:$d),
>>                     (ins RndMode:$r, RegF32:$a, f32imm:$b),
>>                     binary_pattern<opcstrm "f32">.pattern, []>;
>>  def rr64 : InstPTX<(outs RegF64:$d),
>>                     (ins RndMode:$r, RegF64:$a, RegF64:$b),
>>                     binary_pattern<opcstrm "f64">.pattern, []>;
>>  def ri64 : InstPTX<(outs RegF64:$d),
>>                     (ins RndMode:$r, RegF64:$a, f64imm:$b),
>>                     binary_pattern<opcstrm "f64">.pattern, []>;
>> }
>>
>> Would something like that be acceptable?
>
> You are adding complexity for no benefit.  Now I have to look up the definition of InstPTX AND binary_pattern?  This is not helping.
>
> Please focus your efforts on making .td files easy to use as an instruction reference.
>
> Compressing them with clever abstractions is contrary to that.
>
> /jakob
>
>