Replace old notion of "intrinsic" operations

The code previously had an enumerated type for "intrinsic" operations, and allowed functions to be marked `__intrinsic_op(...)` to indicate the operation they map to.
The nature of the IR meant that each of these intrinsic ops had to have a corresponding IR opcode, but the `enum` types weren't the same.
This change cleans things up a bit by deciding that the `__intrinsic_op(...)` modifier names an actual IR opcode, and so the `IntrinsicOp` enum is gone.

The biggest source of complexity here is that there are certain operations that need to be "intrinsic"-ish for the purposes of the current AST-based translation path, because we need them to round-trip from source to AST and back.
Right now this is being handled by defining a bunch of "pseudo-ops" which can be used in the `__intrinsic_op` modifier, but which are *not* meant to be represented in the IR.
Currently I don't actually handle this during IR generation.
In the long run, once we are using IR for everything that needs cross-compilation, we should be able to eliminate the pseudo-ops in favor of just having these be ordinary (inline) functions defined in the stdlib (e.g., the `+=` operator can just have a direct definition).

There was a second category of modifier that gets a little caught up in this, which is the `__intrinsic` modifier, which got used in two ways:

1. A function marked `__intrinsic(glsl, ...)` had what I call a "target intrinsic" modifier, which specified how to lower it for a specific target (e.g., GLSL).

2. A function just marked `__intrinsic` was supposed to be a marker for "this function shouldn't be emitted in the output, because the implementation is expected to be provided"

The latter category of function should really be an `__intrinsic_op`, so I translated all those uses. I added a tiny bit of sugar so that `__intrinsic_op` without an explicit opcode will look up an opcode based on the name of the function being called, so that an operation like `sin` can automatically be plumbed through to an equivalent IR op. (The first category is a stopgap for the AST-based cross-compilation, and will hopefully be replaced by something better  as we get the IR-based path working).

Getting the switch from `__intrinsic` to `__intrinsic_op` working required shuffling around some code in `emit.cpp` that handles looking up those modifiers and emitting builtin operations appropriately during cross-compilation.

Depending on where we go with things, a possible extension of this approach is to allow multiple operands to `__intrinsic_op` so that the first specifies the opcode, and then the rest are literal arguments to specify "sub-ops." This could help us handle stuff like texture-fetch operations without an explosion in the number of opcodes. I still need to think about whether this is a good idea or not.

5 files changed, 5 insertions, 5 deletions

diff --git a/tests/bindings/binding1.hlsl b/tests/bindings/binding1.hlsl
index d9e74e918..b35e4cce1 100644
--- a/tests/bindings/binding1.hlsl
+++ b/tests/bindings/binding1.hlsl
@@ -1,4 +1,4 @@
-//TEST:COMPARE_HLSL: -target dxbc-assembly -profile ps_4_0 -entry main
+//TEST:COMPARE_HLSL: -use-ir -target dxbc-assembly -profile ps_4_0 -entry main
 
 // We want to make sure that the registers that Spire generates
 // are used, even if there are "dead" parameter earlier in the program.
diff --git a/tests/bindings/explicit-binding.hlsl b/tests/bindings/explicit-binding.hlsl
index ac23c6556..b1307ce04 100644
--- a/tests/bindings/explicit-binding.hlsl
+++ b/tests/bindings/explicit-binding.hlsl
@@ -1,4 +1,4 @@
-//TEST:COMPARE_HLSL: -target dxbc-assembly -profile ps_4_0 -entry main
+//TEST:COMPARE_HLSL: -use-ir -target dxbc-assembly -profile ps_4_0 -entry main
 
 // We need to allow the user to add explicit bindings to their parameters,
 // and we can't go and auto-assign anything to use the same locations.
diff --git a/tests/bindings/multi-file.hlsl b/tests/bindings/multi-file.hlsl
index db193a869..6b5848cc8 100644
--- a/tests/bindings/multi-file.hlsl
+++ b/tests/bindings/multi-file.hlsl
@@ -1,4 +1,4 @@
-//TEST:COMPARE_HLSL: -target dxbc-assembly -profile vs_4_0 -entry main Tests/bindings/multi-file-extra.hlsl -profile ps_4_0 -entry main
+//TEST:COMPARE_HLSL: -use-ir -target dxbc-assembly -profile vs_4_0 -entry main Tests/bindings/multi-file-extra.hlsl -profile ps_4_0 -entry main
 
 // Here we are going to test that we can correctly generating bindings when we
 // are presented with a program spanning multiple input files (and multiple entry points)
diff --git a/tests/bindings/packoffset.hlsl b/tests/bindings/packoffset.hlsl
index 787bbc129..8361d754e 100644
--- a/tests/bindings/packoffset.hlsl
+++ b/tests/bindings/packoffset.hlsl
@@ -1,4 +1,4 @@
-//TEST:COMPARE_HLSL: -target dxbc-assembly -profile ps_4_0 -entry main
+//TEST:COMPARE_HLSL: -use-ir -target dxbc-assembly -profile ps_4_0 -entry main
 
 // Let's make sure we generate correct output in cases
 // where there are non-trivial `packoffset`s needed
diff --git a/tests/bindings/resources-in-cbuffer.hlsl b/tests/bindings/resources-in-cbuffer.hlsl
index ec35943cc..080f4e2eb 100644
--- a/tests/bindings/resources-in-cbuffer.hlsl
+++ b/tests/bindings/resources-in-cbuffer.hlsl
@@ -1,4 +1,4 @@
-//TEST:COMPARE_HLSL: -target dxbc-assembly -profile ps_4_0 -entry main
+//TEST:COMPARE_HLSL: -use-ir -target dxbc-assembly -profile ps_4_0 -entry main
 
 // Confirm that resources inside constant buffers get correct locations,
 // including the case where there are *multiple* constant buffers