Allow more complex compound expressions when emitting from IR (#552)

The emit logic already had an idea of when an instruction should be "folded" it its use site(s), and this change just expands on that logic to try to be more aggressive. The basic idea is that instead of outputting this:

```hlsl
float4 _S3 = a_0 + b_0;
float4 _S4 = c_0 * _S3;
d_0 = _S4;
```

we can hopefully output something like this:

```hlsl
d_0 = c_0 * (a_0 + b_0);
```

The way this works is that after dealing with the various special cases that decide an instruction `I` must/cannot be folded in, we look and see if it has the following properites:

* `I` has no side effects
* `I` has a single user, `U`
* `I` and `U` are in the same block (and `I` comes before `U` in that block)
* for every instruction `X` between `I` and `U` (exclusive), `X` has no side effects

If all of these conditions are true, then `I` can be folded in as a sub-expression when we emit `U`.

This change doesn't affect most of our test output, but there is still a single test with SPIR-V output that we compare against a GLSL baseline, and so that baseline had to be modified to match the GLSL we now generate.

Similar to #547, this change is not meant to provide a complete solution, but rather to take a concrete but low-risk step toward improving our output. Opportunities to improve the results further include:

* We can/should ensure that when outputting sub-expressions we keep extra parentheses to a minimum. The old logic for emitting from an AST had support for "unparsing" expressions with minimal parentheses, and we should try to do the same. This can be error-prone, because omitting parentheses can lead to silent failures, so it must be done carefully.

* We could try to be more aggressive about detecting what operations might have side effects. The most interesting case is function calls, where we should try to check if the callee is a function known to be side-effect-free. We could start by annotating most builtin functions with an attribute/decoration that indicates freedom from side effects. Deriving this attribute for user functions could be interesting, but we'd have to be careful since "nontermination" is technically a side effect.

* We could try to be more aggressive about determining what side effects in instructions `X` are "safe" for the instruction `I` to move across. For example, if `I` is a load from variable `a` and `X` is a store to variable `b`, then that would seem to be safe. This starts to get into issues of instruction scheduling, though, and that is probably beyond what we want Slang to be doing.

1 files changed, 5 insertions, 9 deletions

diff --git a/tests/bindings/glsl-parameter-blocks.slang.glsl b/tests/bindings/glsl-parameter-blocks.slang.glsl
index 67aca71dc..01f49279a 100644
--- a/tests/bindings/glsl-parameter-blocks.slang.glsl
+++ b/tests/bindings/glsl-parameter-blocks.slang.glsl
@@ -13,10 +13,9 @@
 #define main_result _S2
 #define uv _S3
 
-#define temp_uv _S4
-#define temp_a _S5
-#define temp_sample _S6
-#define temp_add _S7
+#define temp_a _S4
+#define temp_sample _S5
+#define temp_add _S2
 
 struct Test
 {
@@ -43,14 +42,11 @@ in vec2 uv;
 
 void main()
 {
-	vec2 temp_uv = uv;
-
 	vec4 temp_a = gTest.a;
 
-    vec4 temp_sample = texture(sampler2D(gTest_t, gTest_s), temp_uv);
+    vec4 temp_sample = texture(sampler2D(gTest_t, gTest_s), uv);
 
-    vec4 temp_add = temp_a + temp_sample;
-	main_result = temp_add;
+    main_result = temp_a + temp_sample;
 
 	return;
 }