Fixes for DXR 1.1 RayQuery type (#1227)

The previous change that added `RayQuery` to the standard library didn't mark it as any kind of intrinsic, so the first fix here was to add the appopriate attribtue to the stdlib declaration of `RayQuery`.

Next I found that the legalization pass was obliterating the `RayQuery` type because it had no members, and thus looked like an empty `struct` (which we eliminate for a variety of reasons). I fixed that by adding a check for a target-intrinsic decoration in type legalization.

Next I found that the type wasn't emitted correctly because our generic specialization was turning `RayQuery<0>` into a new type `RayQuery_0` (which is what our specialization is designed to do, after all).
I then disabled generic specialization for types that are marked as target intrinsics (which probably renders the preceding fix moot).

Finally, I found that the emit logic for types in HLSL wasn't handling the case of a generic intrinsic type that didn't also use its own dedicated opcode. I fixes that up by adding a specific case for `IRSpecialize` as a late catch-all.

After all these changes, a declaration of a `RayQuery` variable seems to Just Work (even without any new/improved behavior for handling default constructors).

One potential gotcha looking forward is that my checks for `IRTargetIntrinsicDecoration` aren't checking what target the decoration is for. This is fine for now because there are only two types using the decoration right now (`RayDesc` and `RayQuery`), and the special cases above are reasonable for both of them. If/when we have more target-intrinsic types with this decoration, and some of them are only intrinsic for specific targets, then we will need to revisit this choice and either:

* make these checks perform filtering based on the "current" target (similar to what the emit logic has today), or

* (more likely) make the linking and target-specialization step strip out any target-intrinsic decorations that aren't the right one(s) for the current target

Note that this change doesn't include a test case yet because I don't have a DXR 1.1 ready version of dxc to test against. I have manually confirmed that appropriate Slang input seems to be producing reasonable HLSL output when using these functions, but I cannot yet try to check that in (using an HLSL file for the expected output would be quite fragile).

1 files changed, 12 insertions, 0 deletions

diff --git a/source/slang/slang-ir-specialize.cpp b/source/slang/slang-ir-specialize.cpp
index 5f84da478..6baf8fca5 100644
--- a/source/slang/slang-ir-specialize.cpp
+++ b/source/slang/slang-ir-specialize.cpp
@@ -283,6 +283,18 @@ struct SpecializationContext
                 continue;
             }
 
+            // We should never specialize intrinsic types.
+            //
+            // TODO: This logic assumes that having *any* target
+            // intrinsic decoration makes a type skip specialization,
+            // even if the decoration isn't applicable to the
+            // current target. This should be made true in practice
+            // by having the linking step strip/skip decorations
+            // that aren't applicable to the chosen target at link time.
+            //
+            if(as<IRStructType>(val) && val->findDecoration<IRTargetIntrinsicDecoration>())
+                return false;
+
             // Once we've found the leaf value that will be produced
             // after all specialization is complete, we can check
             // whether it looks like a definition or not.