[PATCH] D47747: [LangRef] Clarify "undefined" for various instructions.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: docs/LangRef.rst:2365
    NaN. Such optimizations are required to retain defined behavior over
-   NaNs, but the value of the result is undefined.
+   NaNs, but the value of the result is unspecified.
 
----------------
nlopes wrote:
> I'm not sure this sentence is clear.
> Does it mean that for NaNs the result has to be the same before and after optimization? Or does it mean that the result after the optimization can be whatever, but fixed (no poison or undef allowed)?
Should be "whatever, but no poison/undef" (there's very little benefit and a lot of risk involved in opening up the possibility of undefined behavior from fast-math).  But yes, should be called out explicitly.


================
Comment at: docs/LangRef.rst:3297
     must be scalars, or vectors of the same number of elements. If the
-    value won't fit in the integer type, the results are undefined.
+    value won't fit in the integer type, the result is ``undef``.
 ``fptosi (CST to TYPE)``
----------------
nlopes wrote:
> Can we have poison here instead? (and for the following ones as well)
Making fptoui produce poison is probably fine.

For uitofp, we should probably consider defining the overflow cases to match the IEEE754 convertFromInt (produce +-Inf).  But that's not what LLVM currently does, so it would involve some code changes.


================
Comment at: docs/LangRef.rst:7314
 Its value is the value at position ``idx`` of ``val``. If ``idx``
-exceeds the length of ``val``, the results are undefined.
+exceeds the length of ``val``, the result is ``undef``.
 
----------------
nlopes wrote:
> can it be poison instead?
Probably, yes; it's not expected, in the same way as an out-of-range shift.


================
Comment at: docs/LangRef.rst:7575
+reclaimed. Allocating zero bytes is legal, but the returned pointer is
+is ``undef``. The order in which memory is allocated (ie., which way the
+stack grows) is not specified.
----------------
nlopes wrote:
> Is undef required by the C/C++ standards or can it be poison?
Actually, thinking about this a bit more, we might need a defined, non-null value.

C and C++ both prohibit zero-size types (arrays can't be zero length, and structs have at least one member in C, and implicit padding in C++).  But there's a GNU extension to allow zero-length arrays.  That extension is usually only used as a replacement for flexible array members in pre-C99 code, but we allow such arrays anywhere.  And given zero-length array variables are allowed, the natural way to lower it is a zero-byte alloca.  This is what clang currently emits.

Given such variables are allowed, we probably need to ensure `&x == &x`, and `&x != 0`, which implies a value that is not poison or undef.


Repository:
  rL LLVM

https://reviews.llvm.org/D47747