[PATCH] D21415: LangRef: Note expectations when loading with extra alignment
Chandler Carruth via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 15 15:17:50 PDT 2016
chandlerc added inline comments.
Comment at: docs/LangRef.rst:7012-7015
@@ -7011,3 +7011,6 @@
may produce less efficient code. An alignment of 1 is always safe. The
-maximum possible alignment is ``1 << 29``.
+maximum possible alignment is ``1 << 29``. An alignment value higher
+than the size of the loaded type implies memory up to the alignment
+value bytes can be safely loaded without trapping in the default
Maybe mention that this is hostile to debugging tools and so shouldn't be done if the function carries the address or thread sanitizer attribute?
Comment at: docs/LangRef.rst:7140-7144
@@ -7136,3 +7139,7 @@
alignment may produce less efficient code. An alignment of 1 is always
-safe. The maximum possible alignment is ``1 << 29``.
+safe. The maximum possible alignment is ``1 << 29``. An alignment
+value higher than the size of thestored type implies memory up to the
+alignment value bytes can be stored to without trapping in the default
+address space. Storing to the higher bytes however may result in data
+races if another thread can access the same address.
This has the same problem as above for address sanitizer (but has no problems for thread sanitizer).
Also, you should probably explicitly state that introducing a data race is not allowed. I don't anyone to be thinking (wrongly) that the race will totally be benign because the value of the bytes are undefined and so its 'fine'.
More information about the llvm-commits