@mrshannon could you share the intended usage of this attribute? Would you be doing it for the whole module, or potentially more granularly?

First, I am specifically talking about precise as it exists in HLSL (rearrangement etc), not signed zero and the rest. We have two use cases:

The first is extremely large scale terrain generation in a compute shader which requires double precision. An existing example of this is Elite Dangerous which uses real doubles on some cards and emulated doubles (which require precise) on others. Their reason for emulation is because it's faster than the real thing on some cards, our reason is because we don't have real doubles at all. In this case, while there will be calculations in the compute shader which do not require precise it is likely that at least half of the compute shader module will require it.

Use in the wild: Generating the Universe in Elite Dangerous

The second case is when rendering very large objects (which cannot be handled in other ways). To avoid jitter we need to perform the model to camera space transform in double precision sometimes. Therefore, again emulated doubles. But in this case the calculation is in the vertex shader and is pretty narrow in scope as it is just used for the model to world transform and furthermore is only used on a small subset of vertices (those close to the camera). Therefore it would be undesirable to require precise at the module level since variable, statement, or function level would allow the disabling of the optimizations at a narrow scope for a tiny part of the vertex shader and in our case only on some invocations.

Use in the wild: 3D Engine Design for Virtual Globes

Conversely, for use cases like games, it's likely that none of the functions in the library will need to be precise.

(Games do need things like the invariant keyword, but that's a different thing.)

This is not true, see Generating the Universe in Elite Dangerous. What is required is not IEEE but specifically the guarantees that HLSL gives with its precise decorator which is more than what invariant guarantees, except on DX12 where invariant maps to precise.

In general there are cases where floating point error needs to be mitigated, even in rendering, which requires controlling the order of operations.