Convert Dot33 to SSE2

[fp64]

Simpler, lower requirements, and doesn't seem to hurt speed. See #17571.

Also removed && !PPSSPP_ARCH(X86). If there was a reason for it being there, please do tell.

[unknownbrackets]

This might crash MSVC builds on x86, especially Debug. Not really a huge issue, but vec is not guaranteed to be aligned if passed on the stack (the stack is only aligned to 16 on x86_64.) I guess we could add a loadu and hope the compiler optimizes it out, but otherwise our "solve" has been to avoid intrinsics for x86_32 when they access XMM args directly.

-[Unknown]

[fp64]

Oof. Didn't realize that MSVC had problems with it, so things like
https://stackoverflow.com/questions/10484422/msvc-cannot-send-function-parameters-of-16byte-alignment-on-x86
https://stackoverflow.com/questions/28488986/formal-parameter-with-declspecalign16-wont-be-aligned
are news to me. Sounds kind of bad.
Sorry about that.

[hrydgard]

Yeah I forgot about it too when merging this. Funnily enough it might not actually even be noticable on recent CPUs since Intel relaxed the alignment requirement for SSE memory operands a while back.. but will affect old ones - which are the more likely ones to run in 32-bit.

[hrydgard]

I'll revert just the ifdef change.

[unknownbrackets]

Intel relaxed the alignment requirement for SSE memory operands a while back.. but will affect old ones - which are the more likely ones to run in 32-bit.

I could be wrong, as I've heard other people say this same thing recently. But I was pretty sure this was ONLY when a VEX prefix is used (i.e. encoded as AVX/AVX2, regardless of using YMMs or not), which none of the non-jit code in PPSSPP is, at least on Windows. At least that's the case on Coffee Lake for sure, which isn't that old.

-[Unknown]

[hrydgard]

Huh, ok. I guess I remember that one wrong then - I've avoided those accesses anyway whenever I can of course..

[fp64]

I guess we could add a loadu and hope the compiler optimizes it out

I'll just mention that movups is as fast as movaps for aligned data starting with Nehalem (Core i7). In fact, compilers often use movups even when implementing _mm_load_ps or equivalent (copying, dereferencing). I think the guarantee is even stronger: you would need to cross a cache line boundary to get a slowdown.
See e.g.:
https://stackoverflow.com/questions/52147378/choice-between-aligned-vs-unaligned-x86-simd-instructions
https://stackoverflow.com/questions/42697118/visual-studio-2017-mm-load-ps-often-compiled-to-movups

Adding _mm_loadu_ps can also change addps reg,mem into movups reg,mem + addps reg,reg, which... might not actually be slower. MSVC (and GCC) seems rather decent at eliminating movups reg,reg, from the simple examples I tried.

So, 'pepper everything with _mm_loadu_ps' approach doesn't seem to have significant drawbacks, other than visual litter.

[unknownbrackets]

Definitely compilers often optimize out loadu, but I have trust issues.

For example, here. On x86_64, ideally, I don't want this on the stack/memory, I want it from a register. An example is Dot33<useSSE4>(H.NormalizedOr001(useSSE4), worldnormal). Realistically, worldnormal is probably spilled, but at least the normalized H (and H itself) could've been XMMs directly. I've seen where a loadu convinces MSVC that it ought to spill the normalized H (although to aligned) just to load it later. I mean, the code DID say to load it from memory, so I guess it's not "wrong".

But some of that may have improved. I just feel like every time I look at a hot func that uses SIMD which MSVC is optimizing poorly, it's because it spills things it should NOT spill like crazy, or even unvectorizes things nonsensically. So I don't want to give it excuses to do that to me.

-[Unknown]

[fp64]

Makes sense.

I suppose it's possible to

#if PPSSPP_ARCH(X86) // Make sure MSVC loads aren't borked.
#define MAGIC_LOAD(v) _mm_loadu_ps(reinterpret_cast<const float*>(&(v)))
#else // Works on non-x86 too!
#define MAGIC_LOAD(v) (v)
#endif

assuming we care enough.