The compiler won't always put the ".xyz" of a hlsl variable into ".xyz" of a register, if that's what you're referring to - sometimes it will move between .xyz, .xyw, .yzw, or even between components in separate registers, depending on if it's some intermediate calculation value or not and how much register pressure there is. As far as I'm aware there's no way to change this, it's just how the internal register allocation handles things. If this swizzling is happening and getting you some wrong output though, that means a bug in RenderDoc :).
You can make it a little easier to read if you disable optimisations and enable the debug flag /Zi or D3DCOMPILE_DEBUG when compiling your shader. That way whenever you have a function that returns a value, it will always compile in a 'mov' instruction that contains the return value, to make it easier to trace what's happening from then on. I think it also makes a 'mov' for each function parameter, but don't quote me on that. In either case, the compiler doesn't try nearly as hard to minimise the number of registers used.
What's all the more infuriating is that modern GPUs have moved away from the SIMD vector style instructions and it all compiles down to scalar operations under the hood, but we're stuck with this old-style fxc!