0

I hope someone is able to help with this issue, which has been bothering me for over an hour now.

I have this code (it is in C): 

#include <immintrin.h>

void test_vectors(__m256i state[5][2]);
void test() {
    __m256i state[5][2];

    for (int i = 0; i < 5; i++) {
        state[i][0] = _mm256_setzero_si256();
        state[i][1] = _mm256_setzero_si256();
    }

    test_vectors(state);
}

void test_vectors(__m256i state[5][2]) {
            __m256i some_new_vector = _mm256_xor_si256(state[0][0], state[0][1]);
}

I cannot build this, as I get the error:

"Error 'state': formal parameter with requested alignment of 32 won't be aligned"

I'm unable to see, what the issue is here. I have specified the dimensions of the array, so the compiler should be able to figure that out. Furthermore I cannot see why the Intel Intrinsics library, should return a __m256i struct that is not aligned, as alignment is required for most of its library-functions.

I am able to avoid the error, by changing the signature of the function to be:

void schwabe_bitsliced_primate(__m256i *state[5]);

However with this, as soon as I access the array, (which I do in the only line in my test_vector method), I get an exception that "struct at NULL". It works fine if the state array parameter is one-dimensional (i.e. only state[5]).

oPolo
  • 516
  • 3
  • 14
  • Can you clarify the workaround you described, involving changing the function signature -- i.e. with actual code? Do note that as the declaration of a function parameter, `__m256i state[5][2]` is equivalent to `__m256i (*state)[2]`, which is entirely different from `__m256i *state[2]`. – John Bollinger May 05 '16 at 14:29
  • Additionally, your code appears to not quite be a [mcve]. It omits the declarations and/or headers for the non-standard data types and the functions manipulating them. – John Bollinger May 05 '16 at 14:52
  • Related: http://stackoverflow.com/questions/28488986/c-opengl-formal-parameter-with-declspecalign16-wont-be-aligned. – John Bollinger May 05 '16 at 14:53
  • 1
    Also, remove at least one of the [avx] and [avx2] tags, and tag the relevant compiler instead, as this is an implementation-specific problem. – John Bollinger May 05 '16 at 14:55
  • Is this Visual Studio, by any chance ? (It seems to compile fine with gcc/clang/ICC). – Paul R May 05 '16 at 15:01
  • Thanks for the response John and Paul! I just corrected my answer to reflect the function signature change I tried. I also changed the code so it should be complete now. Yes, this is with Visual Studio. It seems (based on John's link) that it potentially could be something with the VS compiler. Haven't checked his link thoroughly yet. – oPolo May 05 '16 at 15:09
  • 1
    Yes, Visual Studio has always been notoriously difficult to work with for both SSE and AVX - it imposes bizarre and unnecessary constraints on function parameters etc in regard to alignment, some of which are easy to work around, some not so much. The typical work around is to use pointers in C code (and references in C++) and let the compiler optimise away any indirection when the function is inlined. – Paul R May 05 '16 at 16:45
  • I compiled your code with VS2013 in both 32-bit and 64-bit mode and I get no errors. – Z boson May 12 '16 at 08:13
  • Thanks for the response! Hmm, I wonder if the compiler have changed in VS2016 for C... Although, it would be weird, if it was for the worse. Actually I did find an answer though (based on what John Bollinger wrote), as "__m256i (*state)[2]" worked. I'll update the question with an answer that says so. Thanks! – oPolo May 12 '16 at 08:49
  • I compiled from the command line with `cl /c /O2 /arch:AVX foo.cpp` in 32-bit and 64-bit mode and got to errors. – Z boson May 13 '16 at 08:30

1 Answers1

0

Using "__m256i (*state)[2]" in the signature instead of the aforementioned variations, fixed my alignment issue. John Bollinger suggested this in a comment, so upvotes should first and foremost go to him there.

oPolo
  • 516
  • 3
  • 14