lima: don't split vec3 unaligned load inputs

It seems that the mali400 pp is unable to load vec3 unaligned varyings. This can happen in the current state with mesa if a varying float is put into the first component of a (vec4) varying and a vec3 varying is packed right after it. This would be fine as by default nir would create a vec4 load followed by a mov with swizzle to realign the components into a vec3. In lima_nir_split_load_input, however, this becomes a separate vec3 load expecting the unaligned load. Since this can't happen, skip the load input splitting for this special case.

This is how the bug appears in dEQP-GLES2.functional.shaders.random.texture.fragment.28 (note component=1):

vec3 32 ssa_4 = intrinsic load_input (ssa_7) (0, 1, 160, 0) /* base=0 */ /* component=1 */ /* type=float32 */ /* location=0 slots=0 */  /* packed:b,c */

With this patch, it becomes:

vec4 32 ssa_6 = intrinsic load_input (ssa_9) (0, 0, 160, 169) /* base=0 */ /* component=0 */ /* type=float32 */ /* location=41 slots=1 */       /* packed:b,c */
vec3 32 ssa_3 = mov ssa_6.yzw

Which is sub-optimal but at least valid.

We should investigate if we can prevent this sort of unaligned vec3 packing from happening in the first place, but even then we probably want to have this fallback in lima_nir_split_load_input to prevent invalid code.

Fixes:

dEQP-GLES2.functional.shaders.texture_functions.fragment.texturecube_bias
dEQP-GLES2.functional.shaders.random.texture.fragment.28