When reviewing !1138 (closed), I realized that loop analysis was more broken than it looked on the surface. There are a lot of places where it crawls trees of ALU ops trying to detect such esoteric cases as ((a < b) && c) != 0 and all of that crawling code completely ignored swizzles. Most of the time, this isn't a problem because we get saved by scalarization. However, we still do use NIR loop analysis on vec4 shaders and you can't always be guaranteed that scalarization has happened yet. I was also reminded of another issue I'd seen before where we assume 32 bits all over the place so I cleaned that up while I was there.
The general approach to handling swizzles is to add a new nir_ssa_scalar struct which tracks a nir_ssa_value and an integer component. This struct then has various helpers for crawling ALU trees and converting to nir_const_value that do the right thing with the component. In theory, nir_loop_analyze should be pretty bullet-proof when it comes to this stuff now.