From 46994741406099879d2e46678d4c52b513f47533 Mon Sep 17 00:00:00 2001 From: Andrew Trick Date: Wed, 30 Jan 2013 21:19:35 +0000 Subject: [PATCH] ...in light of recent activity related to llvm.memcpy flags. I want to prevent an llvm developer from mistakenly thinking that just because the intrinsic has volatile flags that volatile operations can be converted to or folded into them. Platforms may rely on volatile loads and stores of natively supported data width to be executed as single instruction. When compiling C, this expectation likely holds for l-values of volatile primitive types with native hardware support, but not necessarily for aggregate types. The frontend upholds these expectations, which are not specified in the IR. llvm-svn: 173974 --- docs/LangRef.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/LangRef.rst b/docs/LangRef.rst index 24a73150dac..ec34a31cd4c 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -1080,6 +1080,11 @@ volatile operations. The optimizers *may* change the order of volatile operations relative to non-volatile operations. This is not Java's "volatile" and has no cross-thread synchronization behavior. +IR-level volatile loads and stores cannot safely be optimized into +llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are +flagged volatile. Likewise, the backend should never split or merge +target-legal volatile load/store instructions. + .. _memmodel: Memory Model for Concurrent Operations