Working on better handling of builtin functions in IR (#196)

The main change I was working on here was to start having more of the builtin functions (in this case, `cos`, `sin`, and `saturate`) just lower to the IR as calls to builtin functions (with declarations but no definition), rather than expect/require them to map to individual IR opcodes in every case.
The main change there was the removal of some `intrinsic_op` modifiers in the stdlib. This then requires the `isTargetInstrinsic` logic in IR-based code emit to avoid emitting declarations for these intrinsics.
The corresponding logic for emitting *calls* to these intrinsics is currently being skipped.

Along the way, a variety of fixups were added:

- In order to support lowering to GLSL, we need to handle cases where a variable/function name uses a GLSL reserved word. The right long-term fix there is to always use generated or mangled names, but for now I'm hacking it by adding a `_s` prefix to all names during IR-based emit.

  - This needs a flag to disable it, since some of our tests currently rely on checking binding information from generated HLSL/SPIR-V that will include these mangled/modified names.

- Emit matrix layout modifiers appropriately for GLSL

- Specialize IR parameter-block emission between GLSL and HLSL

- Fix up argument count/index logic for a couple of opcodes that weren't fixed when removing the types from the explicit operand list

- Fix up IR generation for calls to declarations with generic arguments. We were briefly adding the generic args to the ordinary argument list, which added complexity in several places. We now rely on the declaration-reference nodes in the IR to carry that extra info.

  - TODO: We actually need to make sure that this is the case, since we don't currently correctly generated specialized decl-refs when building IR for function calls

The main test that would have been affected by this is `cross-compile-entry-point`, but I was not able to get that working fully with the IR. The main problem in this case was that when emitting GLSL we will need to perform certain required transformations on the IR to get legal code for GLSL. Notably:

- We need to hoist entry-point parameters away from being function parameters, and make them be global variables. This is currently being hand-waved during the emit logic, but it seems way better to have it all get cleaned up in the IR first.

- We need to scalarize entry-point parameters, because structure input/output is not supported as vertex input or fragment output (and it may be best to always scalarize anyway, to match HLSL semantics). (Note: "scalarize" here means to bust up structures, but not matrices/vectors)

1 files changed, 1 insertions, 1 deletions

diff --git a/tests/bindings/multi-file.hlsl b/tests/bindings/multi-file.hlsl
index 6b5848cc8..aad842a02 100644
--- a/tests/bindings/multi-file.hlsl
+++ b/tests/bindings/multi-file.hlsl
@@ -1,4 +1,4 @@
-//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
+//TEST:COMPARE_HLSL:-no-mangle -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)