[Mesa-dev] nir/i965: Source modifiers on vecN opcodes

[Iago Toral]

Hi,

Currently, NIR defines vecN operations as unsigned (integer). The fp64
patches from Connor change this to float (I guess because we need to
know the case where we are packing vectors of 64-bit floats). However,
this makes it so that  nir_lower_source_to_mods turns this:

	vec1 ssa_2 = fmov -ssa_1.y
	vec3 ssa_3 = vec3 ssa_1, ssa_2, ssa_0
	
into:

	vec3 ssa_2 = vec3 ssa_1, -ssa_1.y, ssa_0

This only happens because the vec3 operation is defined as a float
operation now, otherwise it would not try to do this. It is not clear to
me if this is by design, I mean, have this kind of things only kick-in
for float/int and define vecN operations as unsigned to avoid this for
them.

The problem comes later when we call nir_lower_vec_to_movs in the i965
vec4 backend. That pass generates a separate MOV for each component in
the vector, but to do that properly when a negate is involved it needs
to know if this is a float or an integer operand, which it  does not
know at this point. The current code always emits an imov, which won't
work if the operand is a float.

I can think of two solutions for this:

1) Change nir_lower_source_to_mods so it does not try to rewrite alu
operations where a source comes from a fmov with a negate, or at least
if the instruction we are trying to rewrite is a vecN operation (or
maybe allow this in scalar mode only?)

2) In nir_lower_vec_to_movs, if a source is negated, check its
parent_instr and try to guess its type from that (in this example, we
would see it came from fmov and we can say it is a float and emit fmov
instead of imov). Not sure if this would work in all possible scenarios
though.

Opinions?

Iago