Vectorization generates unaligned moves for properly aligned data

[llvmbot]

Bugzilla Link	39903
Version	trunk
OS	All
Attachments	Code that shows the problem in compiler explorer.
Reporter	LLVM Bugzilla Contributor
CC	@RKSimon,@zygoloid

Extended Description

A simple FMA loop operating on data that is aligned with alignas(64) is generating vmovups instructions when it could, and should, be generating vmovaps.

Since the nehalem architecture the cost of a vmovups relative to vmovaps is not as large as it once was, but it is noticeable and if the data is guaranteed to be aligned, then vmovaps should be the instruction used.

https://www.godbolt.org/z/CCcjYu

[llvmbot]

I meant to add in my original comments, the compiler explorer shows the results in gcc8.2 and in clang trunk. gcc generates and uses the aligned moves, clang does not.

[llvmbot]

Another update. It appears that alignment information about components within the struct is somehow being lost.
At this compiler explorer link I show the original posted code alongside code that has moved the two struct members to global scope. After moving those member to global scope vmovaps is used instead of vmovups. This implies to me that somehow, the alignment information for those arrays is being lost when they are members inside a struct, but is present when the arrays are global.

https://www.godbolt.org/z/AMfjib

[llvmbot]

Yet another update. If I use __builtin_assume(((uintptr_t)(static_cast<void*>(&(event.analyzedChannelData))) % 64) == 0); to force the compiler to assume that the array members of the struct are aligned, the compiler will then generate vmovaps instructions instead of vmovups.

https://www.godbolt.org/z/4qgLO1

However, this makes me think that somehow alignment information of the struct and its members is being lost or not provided to the vectorization system.

[nikic]

Looks like this generates movaps nowadays. Here's a variant with -fno-unroll-loops to cut down on the assembly size: https://www.godbolt.org/z/j56eexjWG