[PATCH] D21415: LangRef: Note expectations when loading with extra alignment

[Chandler Carruth via llvm-commits]

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
+address space.
 
----------------
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'.


http://reviews.llvm.org/D21415