G++ SSE memory alignment on the stack

12
votes

I am attempting to re-write a raytracer using Streaming SIMD Extensions. My original raytracer used inline assembly and movups instructions to load data into the xmm registers. I have read that compiler intrinsics are not significantly slower than inline assembly (I suspect I may even gain speed by avoiding unaligned memory accesses), and much more portable, so I am attempting to migrate my SSE code to use the intrinsics in xmmintrin.h. The primary class affected is vector, which looks something like this:

#include "xmmintrin.h"
union vector {
    __m128 simd;
    float raw[4];
    //some constructors
    //a bunch of functions and operators
} __attribute__ ((aligned (16)));

I have read previously that the g++ compiler will automatically allocate structs along memory boundaries equal to that of the size of the largest member variable, but this does not seem to be occurring, and the aligned attribute isn't helping. My research indicates that this is likely because I am allocating a whole bunch of function-local vectors on the stack, and that alignment on the stack is not guaranteed in x86. Is there any way to force this alignment? I should mention that this is running under native x86 Linux on a 32-bit machine, not Cygwin. I intend to implement multithreading in this application further down the line, so declaring the offending vector instances to be static isn't an option. I'm willing to increase the size of my vector data structure, if needed.

5
c++assemblymemory-managementalignmentsse
If you have a recent version of g++ that supports std::aligned_storage, you can get aligned storage in a way that is portable and will work on other compilers too - James McNellis
what if you bypass the union and just use direct __m128? does that change anything? - Anycorn
Bypassing the union entirely makes it much more painful to access individual members. I have a vectorpacket class as well that gets more benefit out of the SSE than standard vectors, but as an example, my benchmarking indicates that it is faster for me to add the members of a single dot product serially instead of shuffling the register repeatedly to add while remaining in my SSE block. I'm not familiar with std::aligned_storage; that said, my machine has g++ 4.4.3, but there's a second machine I was hoping to be able to run it on that's locked to 3.4.6. - Octavianus
software.intel.com/en-us/forums/showthread.php?t=63876 notice they cast array to m128 types. you can similarly cast m128 to array. - Anycorn
@Anycorn: no, (float*)my_m128 is not safe. The may-alias-anything property of Intel vector types only goes one way, just how you can access anything with char*, but it's not guaranteed safe to access a char[] with an int*. (It's safe in MSVC, which is like gcc -fno-strict-aliasing, but in other compilers you should use unions or shuffle intrinsics to access elements of vectors.) See print a __m128i variable for an example. - Peter Cordes

5 Answers

6
votes

The simplest way is std::aligned_storage, which takes alignment as a second parameter.

If you don't have it yet, you might want to check Boost's version.

Then you can build your union:

union vector {
  __m128 simd;
  std::aligned_storage<16, 16> alignment_only;
}

Finally, if it does not work, you can always create your own little class:

template <typename Type, intptr_t Align> // Align must be a power of 2
class RawStorage
{
public:
  Type* operator->() {
    return reinterpret_cast<Type const*>(aligned());
  }

  Type const* operator->() const {
    return reinterpret_cast<Type const*>(aligned());
  }

  Type& operator*() { return *(operator->()); }
  Type const& operator*() const { return *(operator->()); }

private:
  unsigned char* aligned() {
    if (data & ~(Align-1) == data) { return data; }
    return (data + Align) & ~(Align-1);
  }

  unsigned char data[sizeof(Type) + Align - 1];
};

It will allocate a bit more storage than necessary, but this way alignment is guaranteed.

int main(int argc, char* argv[])
{
  RawStorage<__m128, 16> simd;
  *simd = /* ... */;

  return 0;
}

With luck, the compiler might be able to optimize away the pointer alignment stuff if it detects the alignment is necessary right.

3
votes

A few weeks ago, I had re-written an old ray tracing assignment from my university days, updating it to run it on 64-bit linux and to make use of the SIMD instructions. (The old version incidentally ran under DOS on a 486, to give you an idea of when I last did anything with it).

There very well may be better ways of doing it, but here is what I did ...

typedef float    v4f_t __attribute__((vector_size (16)));

class Vector {
    ...
    union {
        v4f_t     simd;
        float     f[4];
    } __attribute__ ((aligned (16)));

    ...
};

Disassembling my compiled binary showed that it was indeed making use of the movaps instruction.

Hope this helps.

2
votes

Normally all you should need is:

union vector {
    __m128 simd;
    float raw[4];
};

i.e. no additional __attribute__ ((aligned (16))) required for the union itself.

This works as expected on pretty much every compiler I've ever used, with the notable exception of gcc 2.95.2 back in the day, which used to screw up stack alignment in some cases.

1
votes

I use this union trick all the time with __m128 and it works with GCC on Mac and Visual C++ on Windows, so this must be a bug in the compiler that you use.

The other answers contain good workarounds though.

0
votes

If you need an array of N of these objects, allocate vector raw[N+1], and use vector* const array = reinterpret_cast<vector*>(reinterpret_cast<intptr_t>(raw+1) & ~15) as the base address of your array. This will always be aligned.