[LangRef] Do not make align imply dereferenceability (#158062)

We currently specify that something like `load i8, align 16384` implies
that the object is actually dereferenceable up to 16384 bytes, rather
than only the one byte implied by the load type.

We should stop doing that, because it makes it invalid to infer
alignments larger than the load/store type, which is something we do
(and want to do).

There is some SDAG code that does make use of this property by
widening accesses and extracting part of them. However, I believe we
should be justifying that based on target-specific guarantees, rather
than a generic IR property. (The reasoning goes something like this:
Typically, memory protection has page granularity, so widening a load to
the alignment will not trap, as long as the alignment is not larger than
the page size, which is true for any practically interesting access
size.)

Fixes #90446.

Author: nikic

llvm/docs/LangRef.rst

@@ -11397,11 +11397,9 @@ responsibility of the code emitter to ensure that the alignment information is
 correct. Overestimating the alignment results in undefined behavior.
 Underestimating the alignment may produce less efficient code. An alignment of
 1 is always safe. The maximum possible alignment is ``1 << 32``. An alignment
-value higher than the size of the loaded type implies memory up to the
-alignment value bytes can be safely loaded without trapping in the default
-address space. Access of the high bytes can interfere with debugging tools, so
-should not be accessed if the function has the ``sanitize_thread`` or
-``sanitize_address`` attributes.
+value higher than the size of the loaded type does *not* imply (without target
+specific knowledge) that memory up to the alignment value bytes can be safely
+loaded without trapping.
 
 The alignment is only optional when parsing textual IR; for in-memory IR, it is
 always present. An omitted ``align`` argument means that the operation has the
@@ -11537,12 +11535,10 @@ operation (that is, the alignment of the memory address). It is the
 responsibility of the code emitter to ensure that the alignment information is
 correct. Overestimating the alignment results in undefined behavior.
 Underestimating the alignment may produce less efficient code. An alignment of
-1 is always safe. The maximum possible alignment is ``1 << 32``. An alignment
-value higher than the size of the loaded type implies memory up to the
-alignment value bytes can be safely loaded without trapping in the default
-address space. Access of the high bytes can interfere with debugging tools, so
-should not be accessed if the function has the ``sanitize_thread`` or
-``sanitize_address`` attributes.
+1 is always safe. The maximum possible alignment is ``1 << 32``.  An alignment
+value higher than the size of the stored type does *not* imply (without target
+specific knowledge) that memory up to the alignment value bytes can be safely
+loaded without trapping.
 
 The alignment is only optional when parsing textual IR; for in-memory IR, it is
 always present. An omitted ``align`` argument means that the operation has the