intel/compiler/mesh: optimize indirect writes

intel/compiler/mesh: optimize indirect writes

Our hardware requires that we write to URB using full vec4s at aligned
addresses. It gives us an ability to mask-off dwords within vec4 we don't
want to write, but we have to know their positions at compile time.

Let's assume that:
- V represents one dword we want to write
- ? is an unitinitialized value
- "|" is a vec4 boundary.

When we want to write 2-dword value at offset 0 we generate 1 write message:
| V1 V2 ? ? |
with mask:
| 1  1  0 0 |

When we want to write 4-dword value at offset 2 we generate 2 write messages:
| ? ? V1 V2 | V3 V4 ? ? |
with mask:
| 0 0 1  1  | 1  1  0 0 |

However if we don't know the offset within vec4 at *compile time* we
currently generate 4 write messages:
| V1 V1 V1 V1 |
| 0  0  1  0  |

| V2 V2 V2 V2 |
| 0  0  0  1  |

| V3 V3 V3 V3 |
| 1  0  0  0  |

| V4 V4 V4 V4 |
| 0  1  0  0  |

where masks are determined at *run time*.

This is quite wasteful and slow.

However, if we could determine the offset modulo 4 statically at compile time,
we could generate only 1 or 2 write messages (1 if modulo is 0) instead of 4.

This is what this patch does: it analyzes the addressing expression for
modulo 4 value and if it can determine it at compile time, we generate
1 or 2 writes, and if it can't we fallback to the old 4 writes method.

In mesh shader, the value of offset modulo 4 should be known for all outputs,
with an exception of primitive indices.

The modulo value should be known because of MUE layout restrictions, which
require that user per-primitive and per-vertex data start at address aligned
to 8 dwords and we should statically always know the offset from this base.

There can be some cases where the offset from the base is more dynamic
(e.g. indirect array access inside a per-vertex value), so we always do
the analysis.

Primitive indices are an exception, because they form vec3s (for triangles),
which means that the offset will not be easy to analyse.

When U888X index format lands, primitive indices will use only one dword
per triangle, which means that we'll always write them using one message.

Task shaders don't have any predetermined structure of output memory, so
always do the analysis.

Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20050>