[WGSL] Test for round-trippability

Hi!

There has been a fair amount of discussion <https://github.com/gpuweb/gpuweb/issues/622> recently about the process of round-tripping SPIR-V -> WGSL -> SPIR-V. In particular, this round-tripping operation may introduce <https://github.com/gpuweb/gpuweb/issues/579> some modifications to the original source which were not present <https://github.com/gpuweb/gpuweb/issues/581> in the original source. This group has already agreed that the round-trip will not be byte-for-byte identical <https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4qLczmVRWQaomfQmGNzo/edit> to the original source. However, the WGSL group hasn’t come up with a set of criteria for whether not a transformation is too disruptive to the original source to introduce.

It is also accepted practice in WebGL for certain browsers to reject specific versions of certain drivers which are known to have bugs in them. In addition, the WebGPU group has already required certain common Vulkan extensions, thereby effectively rejecting specific Vulkan drivers which don’t support those common extensions.

With all that in mind, I’d like to propose the following test to determine whether a particular construct in the source SPIR-V program must be required to be unperturbed in the round-tripped SPIR-V program:
A class of shaders exists, written in a human-writable shading language, which a human might have reasonably written
… when compiled from that human-writable language into SPIR-V using the latest version of a popular compiler, and then the construct is perturbed (e.g. a variable hoisted, or a const promoted to a variable, or duplicate code moved to a common function, etc.),
… it results in a reproducible and significant performance or correctness problem
… on a shipping system configuration of the most recent version of a major browser (because only new browser versions will get WebGPU)
… which has a significant number of users

If passing this test can be demonstrated, and the specific performance results or incorrect behavior can be displayed publicly (preferably on a WebGPU GitHub issue), then this is a compelling case to redesign WGSL such that it doesn’t require this specific perturbation.

This also goes for HLSL and MSL. If compiling to HLSL or MSL produces a problem which passes this test, then that is is a compelling case to redesign WGSL such that it doesn’t require this problem.

Thanks,
Myles and the rest of the WebKit WebGPU team