On Tue Nov 8 17:49:29 2022 +0000, Francisco Casas wrote:
I see, rebasing !42 over !43 results in
E5017: Aborting due to not yet implemented feature: Object copy.I will investigate further.
The problem is that the test leaves behind an hlsl_ir_load of an object type (instruction 3):
``` trace:hlsl_dump_function 2: float | f trace:hlsl_dump_function 3: Texture2D<float4> | tex trace:hlsl_dump_function 4: float | 1.00000000e+00 trace:hlsl_dump_function 5: float | 2.00000000e+00 trace:hlsl_dump_function 6: float | 3.00000000e+00 trace:hlsl_dump_function 7: uint | 0 trace:hlsl_dump_function 8: | = (a[@7]. @3) trace:hlsl_dump_function 9: uint | 0 trace:hlsl_dump_function 10: | = (a[@9]. @3) trace:hlsl_dump_function 11: uint | 0 trace:hlsl_dump_function 12: | = (a[@11].x @4) trace:hlsl_dump_function 13: uint | 1 trace:hlsl_dump_function 14: | = (a[@13].x @5) trace:hlsl_dump_function 15: uint | 2 trace:hlsl_dump_function 16: | = (a[@15].x @6) trace:hlsl_dump_function 17: uint | 0 trace:hlsl_dump_function 18: float3 | a[@17] trace:hlsl_dump_function 19: float3 | @2.xxx trace:hlsl_dump_function 20: float3 | + (@18 @19 ) trace:hlsl_dump_function 21: float4 | @20.xyzx trace:hlsl_dump_function 22: | return trace:hlsl_dump_function 23: | = (<output-sv_target0> @21) ```
These kinds of hlsl_ir_loads are necessary so that, when there are object loads and stores, copy propagation can make them point their derefs to the static variables, even if they go through several assignments.
However, these types of loads should not reach the sm1/sm4 translations to bytecode because either:
a) If the user made a non-constant dereference to an object type that cannot be solved statically, that is a compilation error and should be caught by the validate_static_object_references pass.
b) If it is a constant dereference, copy propagation should connect the uses of these objects (in resource loads and stores) directly with the uniform variable, and leave the temps without use, so that they are removed by dce.
The problem is that this second case is currently not handled properly because, as Zeb has pointed out in my broaded resources support MR, we currently only detect usage with variable level granularity, not component level granularity. So dce is not cleaning these instructions.
Naturally, the proper solution is detecting usage with a component level granularity. That means making the fields first_write and last_read from hlsl_ir_var component-wise arrays.
I will work on that for my broaden resources support v2 patches.
As for what why the test was passing before the rebase, it is because the test block is written as:
``` [test] uniform 0 float 10.0 todo draw quad probe (0, 0) rgba (11.0, 12.0, 13.0, 11.0) ```
and apparently, after Zebs' patches the `todo` should also be added to `probe`, so I am doing that.