1============================ 2LLVM |release| Release Notes 3============================ 4 5.. contents:: 6 :local: 7 8.. only:: PreRelease 9 10 .. warning:: 11 These are in-progress notes for the upcoming LLVM |version| release. 12 Release notes for previous releases can be found on 13 `the Download Page <https://releases.llvm.org/download.html>`_. 14 15 16Introduction 17============ 18 19This document contains the release notes for the LLVM Compiler Infrastructure, 20release |release|. Here we describe the status of LLVM, including major improvements 21from the previous release, improvements in various subprojects of LLVM, and 22some of the current users of the code. All LLVM releases may be downloaded 23from the `LLVM releases web site <https://llvm.org/releases/>`_. 24 25For more information about LLVM, including information about the latest 26release, please check out the `main LLVM web site <https://llvm.org/>`_. If you 27have questions or comments, the `LLVM Developer's Mailing List 28<https://lists.llvm.org/mailman/listinfo/llvm-dev>`_ is a good place to send 29them. 30 31Note that if you are reading this file from a Git checkout or the main 32LLVM web page, this document applies to the *next* release, not the current 33one. To see the release notes for a specific release, please see the `releases 34page <https://llvm.org/releases/>`_. 35 36Non-comprehensive list of changes in this release 37================================================= 38.. NOTE 39 For small 1-3 sentence descriptions, just add an entry at the end of 40 this list. If your description won't fit comfortably in one bullet 41 point (e.g. maybe you would like to give an example of the 42 functionality, or simply have a lot to talk about), see the `NOTE` below 43 for adding a new subsection. 44 45* ... 46 47Update on required toolchains to build LLVM 48------------------------------------------- 49 50With LLVM 15.x we will raise the version requirements of the toolchain used 51to build LLVM. The new requirements are as follows: 52 53* GCC >= 7.1 54* Clang >= 5.0 55* Apple Clang >= 9.3 56* Visual Studio 2019 >= 16.7 57 58In LLVM 15.x these requirements will be "soft" requirements and the version 59check can be skipped by passing -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=ON 60to CMake. 61 62With the release of LLVM 16.x these requirements will be hard and LLVM developers 63can start using C++17 features, making it impossible to build with older 64versions of these toolchains. 65 66Changes to the LLVM IR 67---------------------- 68 69* LLVM now uses `opaque pointers <OpaquePointers.html>`__. This means that 70 different pointer types like ``i8*``, ``i32*`` or ``void()**`` are now 71 represented as a single ``ptr`` type. See the linked document for migration 72 instructions. 73* Renamed ``llvm.experimental.vector.extract`` intrinsic to ``llvm.vector.extract``. 74* Renamed ``llvm.experimental.vector.insert`` intrinsic to ``llvm.vector.insert``. 75* The constant expression variants of the following instructions have been 76 removed: 77 * ``extractvalue`` 78 * ``insertvalue`` 79 * ``udiv`` 80 * ``sdiv`` 81 * ``urem`` 82 * ``srem`` 83 * ``fadd`` 84 * ``fsub`` 85 * ``fmul`` 86 * ``fdiv`` 87 * ``frem`` 88* Added the support for ``fmax`` and ``fmin`` in ``atomicrmw`` instruction. The 89 comparison is expected to match the behavior of ``llvm.maxnum.*`` and 90 ``llvm.minnum.*`` respectively. 91* ``callbr`` instructions no longer use ``blockaddress`` arguments for labels. 92 Instead, label constraints starting with ``!`` refer directly to entries in 93 the ``callbr`` indirect destination list. 94 95.. code-block:: llvm 96 97 ; Old representation 98 %res = callbr i32 asm "", "=r,r,i"(i32 %x, i8 *blockaddress(@foo, %indirect)) 99 to label %fallthrough [label %indirect] 100 ; New representation 101 %res = callbr i32 asm "", "=r,r,!i"(i32 %x) 102 to label %fallthrough [label %indirect] 103 104Changes to building LLVM 105------------------------ 106 107* Omitting ``CMAKE_BUILD_TYPE`` when using a single configuration generator is now 108 an error. You now have to pass ``-DCMAKE_BUILD_TYPE=<type>`` in order to configure 109 LLVM. This is done to help new users of LLVM select the correct type: since building 110 LLVM in Debug mode is very resource intensive, we want to make sure that new users 111 make the choice that lines up with their usage. We have also improved documentation 112 around this setting that should help new users. You can find this documentation 113 `here <https://llvm.org/docs/CMake.html#cmake-build-type>`_. 114 115Changes to TableGen 116------------------- 117 118Changes to the AArch64 Backend 119------------------------------ 120 121Changes to the AMDGPU Backend 122----------------------------- 123 124* 8 and 16-bit atomic loads and stores are now supported 125 126 127Changes to the ARM Backend 128-------------------------- 129 130* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures. 131* Added support for the Armv8.1-M PACBTI-M extension. 132* Added support for the Armv9-A, Armv9.1-A and Armv9.2-A architectures. 133* Added support for the Armv8.1-M PACBTI-M extension. 134* Removed the deprecation of ARMv8-A T32 Complex IT blocks. No deprecation 135 warnings will be generated and -mrestrict-it is now always off by default. 136 Previously it was on by default for Armv8 and off for all other architecture 137 versions. 138* Added a pass to workaround Cortex-A57 Erratum 1742098 and Cortex-A72 139 Erratum 1655431. This is enabled by default when targeting either CPU. 140* Implemented generation of Windows SEH unwind information. 141* Switched the MinGW target to use SEH instead of DWARF for unwind information. 142* Added support for the Cortex-M85 CPU. 143* Added support for a new -mframe-chain=(none|aapcs|aapcs+leaf) command-line 144 option, which controls the generation of AAPCS-compliant Frame Records. 145 146Changes to the AVR Backend 147-------------------------- 148 149* ... 150 151Changes to the DirectX Backend 152------------------------------ 153 154* DirectX has been added as an experimental target. Specify 155 ``-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=DirectX`` in your CMake configuration 156 to enable it. The target is not packaged in pre-built binaries. 157* The DirectX backend supports the ``dxil`` architecture which is based on LLVM 158 3.6 IR encoded as bitcode and is the format used for DirectX GPU Shader 159 programs. 160 161Changes to the Hexagon Backend 162------------------------------ 163 164* ... 165 166Changes to the MIPS Backend 167--------------------------- 168 169* ... 170 171Changes to the PowerPC Backend 172------------------------------ 173 174* ... 175 176Changes to the RISC-V Backend 177----------------------------- 178 179* The Zvfh extension was added. 180 181Changes to the WebAssembly Backend 182---------------------------------- 183 184* ... 185 186Changes to the X86 Backend 187-------------------------- 188 189* Support ``half`` type on SSE2 and above targets following X86 psABI. 190* Support ``rdpru`` instruction on Zen2 and above targets. 191 192During this release, ``half`` type has an ABI breaking change to provide the 193support for the ABI of ``_Float16`` type on SSE2 and above following X86 psABI. 194(`D107082 <https://reviews.llvm.org/D107082>`_) 195 196The change may affect the current use of ``half`` includes (but is not limited 197to): 198 199* Frontends generating ``half`` type in function passing and/or returning 200arguments. 201* Downstream runtimes providing any ``half`` conversion builtins assuming the 202old ABI. 203* Projects built with LLVM 15.0 but using early versions of compiler-rt. 204 205When you find failures with ``half`` type, check the calling conversion of the 206code and switch it to the new ABI. 207 208Changes to the OCaml bindings 209----------------------------- 210 211 212Changes to the C API 213-------------------- 214 215* Add ``LLVMGetCastOpcode`` function to aid users of ``LLVMBuildCast`` in 216 resolving the best cast operation given a source value and destination type. 217 This function is a direct wrapper of ``CastInst::getCastOpcode``. 218 219* Add ``LLVMGetAggregateElement`` function as a wrapper for 220 ``Constant::getAggregateElement``, which can be used to fetch an element of a 221 constant struct, array or vector, independently of the underlying 222 representation. The ``LLVMGetElementAsConstant`` function is deprecated in 223 favor of the new function, which works on all constant aggregates, rather than 224 only instances of ``ConstantDataSequential``. 225 226* The following functions for creating constant expressions have been removed, 227 because the underlying constant expressions are no longer supported. Instead, 228 an instruction should be created using the ``LLVMBuildXYZ`` APIs, which will 229 constant fold the operands if possible and create an instruction otherwise: 230 * ``LLVMConstExtractValue`` 231 * ``LLVMConstInsertValue`` 232 * ``LLVMConstUDiv`` 233 * ``LLVMConstExactUDiv`` 234 * ``LLVMConstSDiv`` 235 * ``LLVMConstExactSDiv`` 236 * ``LLVMConstURem`` 237 * ``LLVMConstSRem`` 238 * ``LLVMConstFAdd`` 239 * ``LLVMConstFSub`` 240 * ``LLVMConstFMul`` 241 * ``LLVMConstFDiv`` 242 * ``LLVMConstFRem`` 243 244* Add ``LLVMDeleteInstruction`` function which allows deleting instructions that 245 are not inserted into a basic block. 246 247* As part of the opaque pointer migration, the following APIs are deprecated and 248 will be removed in the next release: 249 * ``LLVMBuildLoad`` -> ``LLVMBuildLoad2`` 250 * ``LLVMBuildCall`` -> ``LLVMBuildCall2`` 251 * ``LLVMBuildInvoke`` -> ``LLVMBuildInvoke2`` 252 * ``LLVMBuildGEP`` -> ``LLVMBuildGEP2`` 253 * ``LLVMBuildInBoundsGEP`` -> ``LLVMBuildInBoundsGEP2`` 254 * ``LLVMBuildStructGEP`` -> ``LLVMBuildStructGEP2`` 255 * ``LLVMBuildPtrDiff`` -> ``LLVMBuildPtrDiff2`` 256 * ``LLVMConstGEP`` -> ``LLVMConstGEP2`` 257 * ``LLVMConstInBoundsGEP`` -> ``LLVMConstInBoundsGEP2`` 258 * ``LLVMAddAlias`` -> ``LLVMAddAlias2`` 259 260* Refactor compression namespaces across the project, making way for a possible 261 introduction of alternatives to zlib compression in the llvm toolchain. 262 Changes are as follows: 263 * Relocate the ``llvm::zlib`` namespace to ``llvm::compression::zlib``. 264 * Remove crc32 from zlib compression namespace, people should use the ``llvm::crc32`` instead. 265 266Changes to the Go bindings 267-------------------------- 268 269 270Changes to the FastISel infrastructure 271-------------------------------------- 272 273* ... 274 275Changes to the DAG infrastructure 276--------------------------------- 277 278 279Changes to the Metadata Info 280--------------------------------- 281 282* Add Module Flags Metadata ``stack-protector-guard-symbol`` which specify a 283 symbol for addressing the stack-protector guard. 284 285Changes to the Debug Info 286--------------------------------- 287 288During this release ... 289 290Changes to the LLVM tools 291--------------------------------- 292 293* (Experimental) :manpage:`llvm-symbolizer(1)` now has ``--filter-markup`` to 294 filter :doc:`Symbolizer Markup </SymbolizerMarkupFormat>` into human-readable 295 form. 296* :doc:`llvm-objcopy <CommandGuide/llvm-objcopy>` has removed support for the legacy ``zlib-gnu`` format. 297* :doc:`llvm-objcopy <CommandGuide/llvm-objcopy>` now allows ``--set-section-flags src=... --rename-section src=tst``. 298 ``--add-section=.foo1=... --rename-section=.foo1=.foo2`` now adds ``.foo1`` instead of ``.foo2``. 299* The LLVM gold plugin now ignores bitcode from the ``.llvmbc`` section of ELF 300 files when doing LTO. https://github.com/llvm/llvm-project/issues/47216 301 302Changes to LLDB 303--------------------------------- 304 305* The "memory region" command now has a "--all" option to list all 306 memory regions (including unmapped ranges). This is the equivalent 307 of using address 0 then repeating the command until all regions 308 have been listed. 309* Added "--show-tags" option to the "memory find" command. This is off by default. 310 When enabled, if the target value is found in tagged memory, the tags for that 311 memory will be shown inline with the memory contents. 312* Various memory related parts of LLDB have been updated to handle 313 non-address bits (such as AArch64 pointer signatures): 314 315 * "memory read", "memory write" and "memory find" can now be used with 316 addresses with non-address bits. 317 * All the read and write memory methods on SBProccess and SBTarget can 318 be used with addreses with non-address bits. 319 * When printing a pointer expression, LLDB can now dereference the result 320 even if it has non-address bits. 321 * The memory cache now ignores non-address bits when looking up memory 322 locations. This prevents us reading locations multiple times, or not 323 writing out new values if the addresses have different non-address bits. 324 325* LLDB now supports reading memory tags from AArch64 Linux core files. 326 327* LLDB now supports the gnu debuglink section for reading debug information 328 from a separate file on Windows 329 330* LLDB now allows selecting the C++ ABI to use on Windows (between Itanium, 331 used for MingW, and MSVC) via the ``plugin.object-file.pe-coff.abi`` setting. 332 In Windows builds of LLDB, this defaults to the style used for LLVM's default 333 target. 334 335Changes to Sanitizers 336--------------------- 337 338 339Other Changes 340------------- 341* The code for the `LLVM Visual Studio integration 342 <https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain>`_ 343 has been removed. This had been obsolete and abandoned since Visual Studio 344 started including an integration by default in 2019. 345 346External Open Source Projects Using LLVM 15 347=========================================== 348 349* A project... 350 351Additional Information 352====================== 353 354A wide variety of additional information is available on the `LLVM web page 355<https://llvm.org/>`_, in particular in the `documentation 356<https://llvm.org/docs/>`_ section. The web page also contains versions of the 357API documentation which is up-to-date with the Git version of the source 358code. You can access versions of these documents specific to this release by 359going into the ``llvm/docs/`` directory in the LLVM tree. 360 361If you have any questions or comments about LLVM, please feel free to contact 362us via the `mailing lists <https://llvm.org/docs/#mailing-lists>`_. 363