Add support for (undocumented) HLSL 16-bit bit-cast ops (#1528)

As of SM 6.2, the dxc compiler added support for a set of 16-bit bit-cast operations to mirror the `asuint`, `asfloat`, and `asint` operations that were provided for 32-bit scalar types. These operations are not publicly documented, so we didn't think to add them.

It should be noted that there was already a similar operation in HLSL, called `f32tof16`, that took as input a `float` and then packed a half-precision version of it into the low bits of a `uint`. The problem is that using that operation for `half`->`uint16_t` conversion required a round trip through a `float`, and downstream compilers seemingly can't optimize away that conversion.

This change adds the new operations along with a test that tries to make use of them to ensure the results are what is expected. There are enough cases to cover that I had to write the test in a way where each thread only writes out a subset of the required output.

There are two other changes here are that are not directly related to the main feature:

First, it seems like the `[__forceInlineEarly]` attribute on some of these overloads interacts poorly with generics, and results in an `IRVectorType` appearing at local scope in the output code. That is semantically reasonable given our IR model, but it would ideally be something that gets eliminated as a result of deduplication of types. For now I've introduced a slight hack to make types always get inlined into their use sites during emission, which should handle the case of locally-defined types. I'm not 100% happy with that solution, but it seemed better than introducing a bunch of unrelated fixes into this PR.

Second, the way that conversion operations were being declared for matrix types seems to have been incorrect: we had a single *explicit* initializer added to matrix types via an `extension` that allowed them to be initialized from other matrix types with the same size and *any* element type. In order to support implicit conversions of matrix types, I cribbed the code we were already using to introduce implicit conversion operations for vector types.

1 files changed, 12 insertions, 0 deletions

diff --git a/source/slang/slang-emit-c-like.cpp b/source/slang/slang-emit-c-like.cpp
index d85085639..4b9c01c55 100644
--- a/source/slang/slang-emit-c-like.cpp
+++ b/source/slang/slang-emit-c-like.cpp
@@ -974,6 +974,18 @@ bool CLikeSourceEmitter::shouldFoldInstIntoUseSites(IRInst* inst)
     // for temporary variables.
     auto type = inst->getDataType();
 
+    // We treat instructions that yield a type as things we should *always* fold.
+    //
+    // TODO: In general, at the point where we emit code we do not expect to
+    // find types being constructed locally (inside function bodies), but this
+    // can end up happening because of interaction between different features.
+    // Notably, if a generic function gets force-inlined early in codegen,
+    // then any types it constructs will be inlined into the body of the caller
+    // by default.
+    //
+    if(as<IRType>(inst) || as<IRTypeKind>(type))
+        return true;
+
     // Unwrap any layers of array-ness from the type, so that
     // we can look at the underlying data type, in case we
     // should *never* expose a value of that type