Adding the new SSE instructions as intrinsics

[chuggafan]

Basically, everything shown in Intel's intrinsic guide that we support should be usable, which, afaik, we're doing only SSE & MMX (because MMX is before SSE, we should still have it there if people really want it or happen to have been using it).

This shouldn't be TOO difficult, mostly just tedious, and it might be smart to do #297 so that we only have to generate IR stuff for this then use the backend to generate the rest of it.

[LADSoft]

as part of this we need to do compiler work to make sure the SSE data types are aligned automatically. In function variables this comes in two parts; first any function with a SSE data type as an argument has to align its argument list, and second the EBP variable neesds to be aligned. As this will cause issues with parameters there will have to be some fudging for how parameters are accessed... naturally we would only do this in function with SSE data defined.

[chuggafan]

For the SSE variables we don't necessarily need to align the SSE value in the stack, we would only need to do that on a spill, no?
We don't even need to necessarily do that, only for the most performant methodology, since unaligned access is, while expensive, still possible.

[LADSoft]

I think the rational for doing it is that a lot of the SSE instructions work with aligned values, and it seemed like a lot of the intrinsics assume that that will be the case...

[chuggafan]

There is rationale, I think there needs to be some caution due to the aforementioned "only use what is spilled" criterion, especially since we can just keep things (overall) in registers for most functions and only spill out to the stack when necessary, an example is that strlen code I generated the strlen from #1112.
I'm especially concerned if we make it so that the intrinsics act as "proper" function calls, since that would in theory limit their utility, half the reason I wanted this as "intrinsics" combined with the #577 was that in theory with a bunch of work we can get the optimizer to start filling in registers and precoloring.... which is why I now understand the LLVM approach of treating it as a function call (that just happens to be able to grab the arguments and create a return value, thus allowing the optimizer to take a crack at it much easier than needing to inline the function in a more... gnarly way).
My thinking, of course, on #577 is still oscillating on "best practices" and implementation, and honestly I may just be too into "trying to get it right the first time" to be able to appropriately think that area through....

[LADSoft]

yeah i guess i forgot about the register allocation aspects.... part of that I guess is because when looked at what VC generated it probably generated it in 'debug' mode....