[llvm] [DirectX][DXIL] Design document for TableGen Spec of DXIL Operations (PR #85170)

[S. Bharadwaj Yadavalli via llvm-commits]

bharadwajy wrote:

> If option 3a is expressive enough to cover all our use cases, that seems fine to me. It also would be trivial to allow a hybrid solution where `OpTypes` can either be an array of type specifiers or an array of arrays of type specifiers. That would actually allow solutions 1 and 3a to be used interchangeably or even in mixed capacity. Like:
> 
> ```
> def SillyNewDXOp  : DXILOpMapping<13, unary, int_dx_some_new_intrinsic,
>                          "Returns magic and rainbows!",
>                          [[llvm_halforfloat_ty, LLVMMatchType<0>], [llvm_float_ty, llvm_double_ty]]>;
> ```
>

Is the return type list as shown in the above sample intended to demonstrate the list of all valid overload return types of `SillyNewDXOp`? If so, per my understanding, (a) such a list would be a list of fixed types and (b) `[llvm_halforfloat_ty, LLVMMatchType<0>]` would expand to `[llvm_halforfloat_ty, llvm_halforfloat_ty]`, which doesn't seem to convey additional information. I am assuming that no DXIL operations will return more than one value.

The intent behind defining the more precise overload types `llvm_halforfloat_ty` and `llvm_i16ori32_ty` is to abstract the overload type specification of `[llvm_half_ty, llvm_float_ty]` and `[llvm_i16_ty, llvm_i32_ty]` respectively. A parameter type that is expected to match a previously specified overload type (including these) can be specified via `LLVMMatchType<>`. 

It appears that very few additional precise overload types need to be defined. For example, a common overload type that abstracts an overload of `[llvm_half_ty, llvm_float_ty, llvm_i16_ty, llvm_i32_ty]`, can be defined as `llvm_halforfloatori16ori32_ty`.

> That would allow us the flexibility to simplify where reasonable but still have explicit control where we need it.

I think the specification methodology of option 3a provides the required flexibility and readability.



https://github.com/llvm/llvm-project/pull/85170