Copy unaligned XMVECTOR and use the copy?

I know XMVECTOR has to be 16-byte-aligned and therefore shouldn't be a member of a class (unless I ensure the alignment). However, can I do sth like this?

class A
{
public:
XMVECTOR vect;
};

void fun(void)
{
A a;
XMVECTOR localVect = a.vect;
// can I now use localVect correctly?
}


Edit: My question isn't "Can I use XMVECTOR as a member variable?". It's "Can I copy an XMVECTOR instance that's not guaranteed to be 16-byte aligned into one that is and then use the latter one without any problems?".

• Where do you get the idea that 16-byte-aligned things shouldn't be members of a class? This is fine - it just forces the class as a whole to be 16-byte-aligned as well. – Nathan Reed Jan 6 '14 at 20:39
• @NathanReed this is true as far as he allocating his struct/class on the stack, on the heap AFAIK you need to force it. – concept3d Jan 6 '14 at 20:50
• As I said: "shouldn't be a member of a class (unless I ensure the alignment)". – NPS Jan 6 '14 at 21:07

Answering the question after the edit:

If XMVECTOR was allocated on the stack then the compiler will automatically force it to be 16-byte aligned.

The only case that you have an unaligned XMVECTOR is when it's allocated on the heap, but should't be used at all, because it will result in a seg-fault.

On the other hand if you are accessing the XMVECTOR as a memory chunk using its address, in other words without doing any computation it won't be copied to the SSE registers. You can copy it just like any other POD. The problem isn't accessing the memory, the problem is about using it, so copying it is OK as far as you don't do any math operations that use SSE registers.

• Seems like you didn't get what I was asking about at all. – NPS Jan 6 '14 at 21:11
• @NPS well, the title and the content are confusing. They are fundamentally different. – concept3d Jan 6 '14 at 21:14
• You are absolutely right, even I was surprised when I looked at the title after reading your comment. Well, hope the new title is better. – NPS Jan 7 '14 at 10:55
• As for my question - so my code should copy XMVECTOR's content correctly and then working on a copy (that is aligned) should be fine as well? – NPS Jan 7 '14 at 10:58
• @NPS Yes. Given that you don't try to access it or make any computations that use the SSE registers. so if you make memcpy( dst, src, sizeof(XMVECTOR)) because this operation uses the normal registers and no SSE is involved. – concept3d Jan 7 '14 at 11:21

If you are only building for x64 native, this code is perfectly fine since it is always 16-byte aligned.

class A
{
public:
XMVECTOR vect;
};

void fun(void)
{
A* a = new A;
XMVECTOR localVect = a.vect;
}


To make it portable to x86 or ARM (32-bit), you have one of three choices:

1. Create an overloaded new for the class A that uses __aligned_malloc(,16);
2. Create a global new overload that does this (which is not recommended)
3. Just use XMFLOAT4 or it's kin and explicitly use XMLoadFloat4/XMStoreFloat4

The following code results in the identical compiled code as the block above except that one movaps is now a movups:

class A
{
public:
XMFLOAT4 vect;
};

void fun(void)
{
A* a = new A;
XMVECTOR localVect = XMLoadFloat4( &a.vect );
}


As such, there's no point in messing around with aligned allocations unless it's trivial to do for some other reason (such as DirectX Tool Kit's use of the pImpl idiom which means we might as well align the internal class allocations to make it convenient).

If your complaint is just the extra work it takes to use XMVECTOR correctly with respect to the alignment, you could take a look at using SimpleMath from the DirectX Tool Kit.