[llvm] 98e5776 - [LangRef] State that storing an aggregate fills padding with undef

[Juneyoung Lee via llvm-commits]

Author: Juneyoung Lee
Date: 2020-08-30T14:53:20+09:00
New Revision: 98e5776897cec9e836d3b13b1f5ce34604eabfec

URL: https://github.com/llvm/llvm-project/commit/98e5776897cec9e836d3b13b1f5ce34604eabfec
DIFF: https://github.com/llvm/llvm-project/commit/98e5776897cec9e836d3b13b1f5ce34604eabfec.diff

LOG: [LangRef] State that storing an aggregate fills padding with undef

This patch makes LangRef be explicit about the value of padding when storing an aggregate.
It states that when an aggregate is stored into memory, padding is filled with undef.

Here is a clue that supports this change (edited to reflect the discussion from llvm-dev):

- IPSCCP ignores padding and directly stores a constant aggregate if possible. It loses the data stored in the padding. https://godbolt.org/z/xzenYs Memcpyopt ignores (the preexisting value of) padding when copying an aggregate or storing a constant: https://godbolt.org/z/hY6ndd / https://godbolt.org/z/3WMP5a

The two items below are not relevant with this patch because Clang lowers load/store of individual field of struct into load/stores of the corresponding pointer with a primitive type. Also, when copy is needed, it uses memcpy instead of load/store of an aggregate, as discussed in the llvm-dev. However, this patch is still valid (as discussed) because it is needed to explain the two optimizations above.

- According to C17, the value of padding bytes when storing values in structures or unions is unspecified.

- I updated Alive2 and it did not find any problematic transformation from LLVM unit tests and while running translation validation of a few C programs.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D86189

Added: 
    

Modified: 
    llvm/docs/LangRef.rst

Removed: 
    


################################################################################
diff  --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index fdeb5d9b5196..1c8143772108 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -9239,6 +9239,9 @@ example, loading an ``i24`` reads at most three bytes. When loading a
 value of a type like ``i20`` with a size that is not an integral number
 of bytes, the result is undefined if the value was not originally
 written using a store of the same type.
+If the value being loaded is of aggregate type, the bytes that correspond to
+padding may be accessed but is ignored, because it is impossible to observe
+padding from the loaded aggregate value.
 
 Examples:
 """""""""
@@ -9328,6 +9331,8 @@ example, storing an ``i24`` writes at most three bytes. When writing a
 value of a type like ``i20`` with a size that is not an integral number
 of bytes, it is unspecified what happens to the extra bits that do not
 belong to the type, but they will typically be overwritten.
+If ``<value>`` is of aggregate type, padding is filled with
+:ref:`undef <undefvalues>`.
 
 Example:
 """"""""