[PATCH] D95174: Revert "[LangRef] Clarify the behavior of memory access instructions when pointers/sizes aren't well-defined"

Dávid Bolvanský via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 21 14:42:50 PST 2021


xbolva00 created this revision.
xbolva00 added reviewers: nikic, jdoerfert, aqjune.
xbolva00 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

As discussed in D95122 <https://reviews.llvm.org/D95122>, this change makes noundef unusable for futher optimizations - more info in D95122 <https://reviews.llvm.org/D95122>.

As reviewers suggested, we should revert this decision/patch.


https://reviews.llvm.org/D95174

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -3596,6 +3596,10 @@
 
 To ensure all uses of a given register observe the same value (even if
 '``undef``'), the :ref:`freeze instruction <i_freeze>` can be used.
+A value is frozen if its uses see the same value.
+An aggregate value or vector is frozen if its elements are frozen.
+The padding of an aggregate isn't considered, since it isn't visible
+without storing it into memory and loading it with a different type.
 
 .. code-block:: llvm
 
@@ -3769,22 +3773,6 @@
 
     end:
 
-.. _welldefinedvalues:
-
-Well-Defined Values
--------------------
-
-Given a program execution, a value is *well defined* if the value does not
-have an undef bit and is not poison in the execution.
-An aggregate value or vector is well defined if its elements are well defined.
-The padding of an aggregate isn't considered, since it isn't visible
-without storing it into memory and loading it with a different type.
-
-A constant of a :ref:`single value <t_single_value>`, non-vector type is well
-defined if it is neither '``undef``' constant nor '``poison``' constant.
-The result of :ref:`freeze instruction <i_freeze>` is well defined regardless
-of its operand.
-
 .. _blockaddress:
 
 Addresses of Basic Blocks
@@ -9435,12 +9423,6 @@
 padding may be accessed but are ignored, because it is impossible to observe
 padding from the loaded aggregate value.
 
-If the pointer is not a well-defined value, all of its possible representations
-should be dereferenceable. For example, loading a byte from a pointer to an
-array of type ``[16 x i8]`` with offset ``undef & 31`` is undefined behavior.
-Loading a byte at offset ``undef & 15`` nondeterministically reads one of the
-bytes.
-
 Examples:
 """""""""
 
@@ -9534,12 +9516,6 @@
 If ``<value>`` is of aggregate type, padding is filled with
 :ref:`undef <undefvalues>`.
 
-If ``<pointer>`` is not a well-defined value, all of its possible
-representations should be dereferenceable. For example, storing a byte to a
-pointer to an array of type ``[16 x i8]`` with offset ``undef & 31`` is
-undefined behavior. Storing a byte to an offset ``undef & 15``
-nondeterministically stores to one of offsets from 0 to 15.
-
 Example:
 """"""""
 
@@ -12705,9 +12681,6 @@
 
 If "len" is 0, the pointers may be NULL, dangling, ``undef``, or ``poison``
 pointers. However, they must still be appropriately aligned.
-If "len" isn't a well-defined value, all of its possible representations should
-make the behavior of this ``llvm.memcpy`` defined, otherwise the behavior is
-undefined.
 
 .. _int_memcpy_inline:
 
@@ -12825,9 +12798,6 @@
 
 If "len" is 0, the pointers may be NULL, dangling, ``undef``, or ``poison``
 pointers. However, they must still be appropriately aligned.
-If "len" isn't a well-defined value, all of its possible representations should
-make the behavior of this ``llvm.memmove`` defined, otherwise the behavior is
-undefined.
 
 .. _int_memset:
 
@@ -12883,9 +12853,6 @@
 
 If "len" is 0, the pointer may be NULL, dangling, ``undef``, or ``poison``
 pointer. However, it must still be appropriately aligned.
-If "len" isn't a well-defined value, all of its possible representations should
-make the behavior of this ``llvm.memset`` defined, otherwise the behavior is
-undefined.
 
 '``llvm.sqrt.*``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D95174.318318.patch
Type: text/x-patch
Size: 3449 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210121/62c7b853/attachment.bin>


More information about the llvm-commits mailing list