[docs] Mention in release notes that we now support 2^32 alignment

[aeubanks]

Summary

Missed in D110451.

[hans]

Nice. Might be worth mentioning in Clang's release notes too.

[aeubanks]

mention in Clang release notes as well

llvm/docs/LangRef.rst

 power of 2. If not present, or if the alignment is set to zero, the
 alignment of the global is set by the target to whatever it feels
 convenient. If an explicit alignment is specified, the global is forced
 to have exactly that alignment. Targets and optimizers are not allowed
 to over-align the global if the global has an assigned section. In this
 case, the extra alignment could be observable: for example, code could
 assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
-iteration. The maximum alignment is ``1 << 29``.
+iteration. The maximum alignment is ``1 << 32``.
 
 For global variables declarations, as well as definitions that may be
 replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common``
 linkage types), LLVM makes no assumptions about the allocation size of the
 variables, except that they may not overlap. The alignment of a global variable
 declaration or replaceable definition must not be greater than the alignment of
 the definition it resolves to.
 

 """"""""""
 
 The '``alloca``' instruction allocates ``sizeof(<type>)*NumElements``
 bytes of memory on the runtime stack, returning a pointer of the
 appropriate type to the program. If "NumElements" is specified, it is
 the number of elements allocated, otherwise "NumElements" is defaulted
 to be one. If a constant alignment is specified, the value result of the
 allocation is guaranteed to be aligned to at least that boundary. The
-alignment may not be greater than ``1 << 29``. If not specified, or if
+alignment may not be greater than ``1 << 32``. If not specified, or if
 zero, the target can choose to align the allocation on any convenient
 boundary compatible with the type.
 
 '``type``' may be any sized type.
 
 Semantics:
 """"""""""
 

 
 The optional constant ``align`` argument specifies the alignment of the
 operation (that is, the alignment of the memory address). A value of 0
 or an omitted ``align`` argument means that the operation has the ABI
 alignment for the target. 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 << 29``. An alignment value higher
+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.
 
 The optional ``!nontemporal`` metadata must reference a single
 metadata name ``<nontemp_node>`` corresponding to a metadata node with one

 
 The optional constant ``align`` argument specifies the alignment of the
 operation (that is, the alignment of the memory address). A value of 0
 or an omitted ``align`` argument means that the operation has the ABI
 alignment for the target. 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 << 29``. An alignment
+safe. The maximum possible alignment is ``1 << 32``. An alignment
 value higher than the size of the stored type implies memory up to the
 alignment value bytes can be stored to without trapping in the default
 address space. Storing to the higher bytes however may result in data
 races if another thread can access the same address. Introducing a
 data race is not allowed. Storing to the extra bytes is not allowed
 even in situations where a data race is known to not exist if the
 function has the ``sanitize_address`` attribute.
 

llvm/docs/ReleaseNotes.rst

 
 Changes to the LLVM IR
 ----------------------
 
 * Using the legacy pass manager for the optimization pipeline is deprecated and
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
+* Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 ------------------------
 
 * ...
 
 Changes to TableGen
 -------------------