http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60086
--- Comment #2 from Marcin Krotkiewski <marcin.krotkiewski at gmail dot com> --- Jakub, thank you for your comments. > GCC right now only handles __restrict on function parameters, so in this > case the aliasing info isn't known. While the loop is versioned for > aliasing at runtime, the info about that is only known during the > vectorizer, therefore e.g. scheduler can hardly know it. Does it mean that __restrict is not necessary in order to have a vectorized code path? I see that if I compile your modified test.c, the loop is vectorized regardless of whether I use __restrict, or not (runtime versioning). On the other hand, using __restrict causes gcc to invoke memset for initialization, while leaving it out results in two paths with a loop. On the interesting side. Your test.c works indeed if compiled with additional -fschedule-insns flag. However, if I now remove the __restrict keyword from function arguments, I do see a vectorized path, but the flag has no effect and instructions are again not reordered. > The pointers to > overaligned memory is something you should generally avoid, > __builtin_assume_aligned is what can be used to tell the compiler about the > alignment instead, overaligned types often actually hurt generated code > instead of improving it. Thanks. Could you suggest what is the preferred way to use it in a portable manner? e.g. make it suitable for icc, which has a __assume_aligned builtin? Should I wrap it in a macro? > And the way you are calling posix_memalign is IMHO > a strict aliasing violation. Could be, gcc des not show a warning with -Wall. Thanks for pointing it out.
