[all-commits] [llvm/llvm-project] 98e577: [LangRef] State that storing an aggregate fills pa...

[Juneyoung Lee via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 98e5776897cec9e836d3b13b1f5ce34604eabfec
      https://github.com/llvm/llvm-project/commit/98e5776897cec9e836d3b13b1f5ce34604eabfec
  Author: Juneyoung Lee <aqjune at gmail.com>
  Date:   2020-08-30 (Sun, 30 Aug 2020)

  Changed paths:
    M llvm/docs/LangRef.rst

  Log Message:
  -----------
  [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