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

[Chris B via llvm-commits]

https://github.com/llvm-beanz commented:

My $0.02 on reading the content here is that options 2 and 3b don't really accomplish our key goal of making the tablegen a source of truth for DXIL specification.

With option 2 we need to have an external tool that validates the tablegen, which means the tablegen files themselves can't be treated as the source of truth.

For option 3b, again, the tablegen isn't really a clear source of truth. I think having an exclusion list is fragile (what happens if we add a new type), and much less intuitive because nothing about the op declaration clearly conveys that these are the disallowed types rather than the allowed types you just have to know it.

Option 4 seems confusing to me. LLVM's Attr class is for defining IR attributes. I'm not sure how or why we would use attributes for defining the valid overloads.

IIUC, the only real difference between option 1 and option 3a, is that option 3a uses types that can map to one or more type and type matching rather than an array of explicit overloads.

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]]>;
```

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

I have a strong preference for either option 1, 3a, or a hybrid approach. I think that is the most straight forward and simple. Curious if @bogner has other thoughts.

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