IADD.v2i16 supports swapping lanes, LSHIFT_XOR.v2i16 does not support any sort of swizzle (on the xor).

Consider the NIR

	16 vec2 ssa_0 = ...
	16 vec2 ssa_1 = ...
	16 vec2 ssa_2 = iadd ssa_0, ssa_1
	16 vec2 ssa_3 = ixor ssa_0, ssa_2.yx

If we tried to translate directly into backend IR, we'd get the following code which is NOT encodeable:

	0 = ...
	1 = ...
	2 = IADD.v2i16 0, 1
	3 = LSHIFT_XOR.v2i16 0, 2.yx, #0

However, we may lower away the swizzle in NIR so everything uses identity swizzles

	16 vec2 ssa_0 = ...
	16 vec2 ssa_1 = ...
	16 vec2 ssa_2 = iadd ssa_0, ssa_1
	16 vec2 ssa_4 = mov ssa_2.yx
	16 vec2 ssa_3 = ixor ssa_0, ssa_4

And then translate directly into code that _is_ encodeable

	0 = ...
	1 = ...
	2 = IADD.v2i16 0, 1
	4 = SWZ.v2i16 2.yx
	3 = LSHIFT_XOR.v2i16 0, 4, #0

Finally, a backend pass can attempt to propagate the swizzle. It would try to propagate downward into the LSHIFT_XOR, but that is not possible. However, it can also propagate upwards if 1) the SWZ is the only use of its source 2) source and dest are both SSA -- could maybe be relaxed 3) def can accept the composition of this swizzle with the swizzle on _all_ of its source 4) def operates componentwise. Since all of these conditions are met here, the pass may rewrite to

	0 = ...
	1 = ...
	4 = IADD.v2i16 0.yx, 1.yx
	3 = LSHIFT_XOR.v2i16 0, 4, #0