memcpy/memmove/memset intrinsics are unclear about alignment value 0

[llvmbot]

Bugzilla Link	8388
Resolution	FIXED
Resolved on	Oct 18, 2013 18:27
Version	trunk
OS	All
Blocks	llvm/llvm-bugzilla-archive#10637
Reporter	LLVM Bugzilla Contributor
CC	@isanbard

Extended Description

The docs for llvm.memcpy., llvm.memmove., and llvm.memset.* say the following about alignment value 0:

"If the call to this intrinsic has an alignment value that is not 0 or 1, then the caller guarantees that both the source and destination pointers are aligned to that boundary."

"If the argument is known to be aligned to some boundary, this can be specified as the fourth argument, otherwise it should be set to 0 or 1."

This seems to imply that an alignment value of 0 has the same effect as 1. At best, it doesn't say what 0 means.

For the 'load' and 'store' instructions, the docs say that a value of 0 allows the backend to assume the best alignment for the target. This seems to be the actual behaviour for the llvm.mem*.* intrinsics as well. For example, the memset in the following gets codegenned to a 'movaps', causing a segfault with llc -O0 (-O1 and above get lucky with the choice of stack slot):

target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"
define i32 @​main() {
%a = alloca [4 x i32], align 1
%p = bitcast [4 x i32]* %a to i8*
call void @​llvm.memset.p0i8.i64(i8* %p, i8 0, i64 16, i32 0, i1 false)
ret i32 0
}
declare void @​llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, i1) nounwind

The docs could use some clarification and say that if the alignment value is 0, it's treated as meaning arbitrary alignment.

[isanbard]

Clarified here:

Sending docs/LangRef.rst
Transmitting file data .
Committed revision 193012.

The behavior wasn't the same as with the store or load instructions. Both 0 and 1 indicate that there is no alignment with these intrinsics.