From b41cfbfcbbe27d519171b5847a8d44ca8a5a0f13 Mon Sep 17 00:00:00 2001 From: Arthur Eubanks Date: Mon, 11 Oct 2021 10:19:43 -0700 Subject: [PATCH] [docs] Mention in release notes that we now support 2^32 alignment Missed in D110451. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D111472 --- clang/docs/ReleaseNotes.rst | 1 + llvm/docs/LangRef.rst | 8 ++++---- llvm/docs/ReleaseNotes.rst | 1 + 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst index f32ea39a77182b..70dbc58030d0dd 100644 --- a/clang/docs/ReleaseNotes.rst +++ b/clang/docs/ReleaseNotes.rst @@ -121,6 +121,7 @@ C Language Changes in Clang `P2362 `_. - Support for ``__attribute__((error("")))`` and ``__attribute__((warning("")))`` function attributes have been added. +- The maximum allowed alignment has been increased from 2^29 to 2^32. C++ Language Changes in Clang ----------------------------- diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 587f694519c918..3f6349bb8afb28 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -709,7 +709,7 @@ 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`` @@ -9736,7 +9736,7 @@ 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. @@ -9826,7 +9826,7 @@ 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 @@ -9961,7 +9961,7 @@ 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 diff --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst index fa0adbbeb6a1e4..46627c20006794 100644 --- a/llvm/docs/ReleaseNotes.rst +++ b/llvm/docs/ReleaseNotes.rst @@ -60,6 +60,7 @@ Changes to the LLVM IR 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 ------------------------