[llvm-dev] TableGen: Named template arguments

[Nicolai Hähnle via llvm-dev]

Hi Paul,

On Mon, Nov 2, 2020 at 8:14 PM Paul C. Anagnostopoulos via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Here is a TableGen feature that I think would be useful, but I'd like some feedback.
>
> TableGen would allow the template arguments in a class or multiclass invocation to be named (in the venerable tradition of macro arguments). For example:
>
> class InstSubst<string Asm, dag Result, bit EmitPriority = 0>
>   : InstAlias<Asm, Result, EmitPriority>, Requires<[UseNegativeImmediates]>;
>
> This class could be invoked as follows:
>
>   def : InstSubst<Result: (!cast<Instruction>(NAME # "Wri") GPR32sp:$Rd,
>                                        GPR32:$Rn, logical_imm32_not:$imm),
>                          Asm: Alias # "\t$Rd, $Rn, $imm",
>                          EmitPriority: 0>;

I assume `Alias` is defined externally, e.g. because you took this
example from a multiclass definition?


> Note that each template argument is named, so that they do not have to be in order. An argument list could start with positional arguments and then switch to named arguments, but not vice versa.

This is a pretty natural idea, but I'd like to think through some
implications a bit more.

There is a bit of implicit overlap between what you're proposing here
and the `let` facility combined with late resolution. In the past, I
have occasionally resisted the urge to add more template parameters
consciously, because having so many parameters with meaningful
positions tends to make for hard-to-read instantiations. I then solved
the problem you're proposing to solve here with named parameters with
`let` statements instead.

So there is a bit of a risk of having multiple ways of saying the same thing.

Then again: the `let` approach doesn't work when using classes for
functional programming; and perhaps we should consider too much late
resolution a bad thing anyway.

Do you have a concrete use case for this?

I think I'd tentatively say I'd be okay with adding this, but only if
we have a compelling near-term use case for it; otherwise, we're
adding unused features to TableGen which risks bit-rot.

Cheers,
Nicolai