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

[aqjune]

Summary

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.

[efriedma]

Makes sense.

llvm/docs/LangRef.rst

9331

Probably makes sense to add corresponding language to loads (that they ignore the padding).

[jdoerfert]

I would like to keep the SCCP reasoning and I don't have any knowledge of it being problematic. Given that we already apply this semantic, I doubt too many people would be offended by specifying it.

[aqjune]

Mention that load ignores padding of aggregate.

[efriedma]

llvm/docs/LangRef.rst

9242

"is not read" might be a little strong; I'm not sure we want to promise the generated code won't access the address in question, just that the bytes in question aren't part of the value representation.

[aqjune]

Update wording

[aqjune]

llvm/docs/LangRef.rst

9242

Yes, what I intended to say was that it is accessed but not participate into the returned value. Updated the sentence

[nikic]

LGTM

llvm/docs/LangRef.rst

9242

[aqjune]

llvm/docs/LangRef.rst

9242

https://github.com/llvm/llvm-project/commit/09dcb52ca83b325f6de76b69bc543122de58cde9

llvm/docs/LangRef.rst

 The location of memory pointed to is loaded. If the value being loaded
 is of scalar type then the number of bytes read does not exceed the
 minimum number of bytes needed to hold all bits of the type. For
 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.
 
 Examples:
 """""""""
 
 .. code-block:: llvm
 
       %ptr = alloca i32                               ; yields i32*:ptr
       store i32 3, i32* %ptr                          ; yields void
       %val = load i32, i32* %ptr                      ; yields i32:val = i32 3
 

 The contents of memory are updated to contain ``<value>`` at the
 location specified by the ``<pointer>`` operand. If ``<value>`` is
 of scalar type then the number of bytes written does not exceed the
 minimum number of bytes needed to hold all bits of the type. For
 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:
 """"""""
 
 .. code-block:: llvm
 
       %ptr = alloca i32                               ; yields i32*:ptr
       store i32 3, i32* %ptr                          ; yields void