llvm/docs/ReleaseNotes.rst

   1 ============================
   2 LLVM |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
  16 Introduction
  17 ============
  18
  19 This document contains the release notes for the LLVM Compiler Infrastructure,
  20 release |release|.  Here we describe the status of LLVM, including major improvements
  21 from the previous release, improvements in various subprojects of LLVM, and
  22 some of the current users of the code.  All LLVM releases may be downloaded
  23 from the `LLVM releases web site <https://llvm.org/releases/>`_.
  24
  25 For more information about LLVM, including information about the latest
  26 release, please check out the `main LLVM web site <https://llvm.org/>`_.  If you
  27 have questions or comments, the `Discourse forums
  28 <https://discourse.llvm.org>`_ is a good place to ask
  29 them.
  30
  31 Note that if you are reading this file from a Git checkout or the main
  32 LLVM web page, this document applies to the *next* release, not the current
  33 one.  To see the release notes for a specific release, please see the `releases
  34 page <https://llvm.org/releases/>`_.
  35
  36 Non-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
  47 Update on required toolchains to build LLVM
  48 -------------------------------------------
  49
  50 With LLVM 17.x we raised the version requirement of CMake used to build LLVM.
  51 The new requirements are as follows:
  52
  53 * CMake >= 3.20.0
  54
  55 Changes to the LLVM IR
  56 ----------------------
  57
  58 * Typed pointers are no longer supported. See the `opaque pointers
  59   <OpaquePointers.html>`__ documentation for migration instructions.
  60
  61 * The ``nofpclass`` attribute was introduced. This allows more
  62   optimizations around special floating point value comparisons.
  63
  64 * Introduced new ``llvm.ldexp`` and ``llvm.experimental.constrained.ldexp`` intrinsics.
  65
  66 * The constant expression variants of the following instructions have been
  67   removed:
  68
  69   * ``select``
  70
  71 Changes to LLVM infrastructure
  72 ------------------------------
  73
  74 * The legacy optimization pipeline has been removed.
  75
  76 * Alloca merging in the inliner has been removed, since it only worked with the
  77   legacy inliner pass. Backend stack coloring should handle cases alloca
  78   merging initially set out to handle.
  79
  80 * InstructionSimplify APIs now require instructions be inserted into a
  81   parent function.
  82
  83 Changes to building LLVM
  84 ------------------------
  85
  86 Changes to TableGen
  87 -------------------
  88
  89 Changes to Interprocedural Optimizations
  90 ----------------------------------------
  91
  92 Changes to the AArch64 Backend
  93 ------------------------------
  94
  95 * Added Assembly Support for the 2022 A-profile extensions FEAT_GCS (Guarded
  96   Control Stacks), FEAT_CHK (Check Feature Status), and FEAT_ATS1A.
  97 * Support for preserve_all calling convention is added.
  98 * Added support for missing arch extensions in the assembly directives
  99   ``.arch <level>+<ext>`` and ``.arch_extension``.
 100 * Fixed handling of ``.arch <level>`` in assembly, without using any ``+<ext>``
 101   suffix. Previously this had no effect at all if no extensions were supplied.
 102   Now ``.arch <level>`` can be used to enable all the extensions that are
 103   included in a higher level than what is specified on the command line,
 104   or for disabling unwanted extensions if setting it to a lower level.
 105   This fixes `PR32873 <https://github.com/llvm/llvm-project/issues/32220>`.
 106
 107 Changes to the AMDGPU Backend
 108 -----------------------------
 109 * More fine-grained synchronization around barriers for newer architectures
 110   (gfx90a+, gfx10+). The AMDGPU backend now omits previously automatically
 111   generated waitcnt instructions before barriers, allowing for more precise
 112   control. Users must now use memory fences to implement fine-grained
 113   synchronization strategies around barriers. Refer to `AMDGPU memory model
 114   <AMDGPUUsage.html#memory-model>`__.
 115
 116 * Address space 7, used for *buffer fat pointers* has been added.
 117   It is non-integral and has 160-bit pointers (a 128-bit raw buffer resource and a
 118   32-bit offset) and 32-bit indices. This is part of ongoing work to improve
 119   the usability of buffer operations. Refer to `AMDGPU address spaces
 120   <AMDGPUUsage.html#address-spaces>`__.
 121
 122 * Address space 8, used for *buffer resources* has been added.
 123   It is non-integral and has 128-bit pointers, which correspond to buffer
 124   resources in the underlying hardware. These pointers should not be used with
 125   `getelementptr` or other LLVM memory instructions, and can be created with
 126   the `llvm.amdgcn.make.buffer.rsrc` intrinsic. Refer to `AMDGPU address spaces
 127   <AMDGPUUsage.html#address_spaces>`__.
 128
 129 * New versions of the intrinsics for working with buffer resources have been added.
 130   These `llvm.amdgcn.*.ptr.[t]buffer.*` intrinsics have the same semantics as
 131   the old `llvm.amdgcn.*.[t]buffer.*` intrinsics, except that their `rsrc`
 132   arguments are represented by a `ptr addrspace(8)` instead of a `<4 x i32>`. This
 133   improves the interaction between AMDGPU buffer operations and the LLVM memory
 134   model, and so the non `.ptr` intrinsics are deprecated.
 135
 136 * Added llvm.amdgcn.log.f32 intrinsic. This provides direct access to
 137   v_log_f32.
 138
 139 * Added llvm.amdgcn.exp2.f32 intrinsic. This provides direct access to
 140   v_exp_f32.
 141
 142
 143 Changes to the ARM Backend
 144 --------------------------
 145
 146 - The hard-float ABI is now available in Armv8.1-M configurations that
 147   have integer MVE instructions (and therefore have FP registers) but
 148   no scalar or vector floating point computation.
 149
 150 - The ``.arm`` directive now aligns code to the next 4-byte boundary, and
 151   the ``.thumb`` directive aligns code to the next 2-byte boundary.
 152
 153 Changes to the AVR Backend
 154 --------------------------
 155
 156 * ...
 157
 158 Changes to the DirectX Backend
 159 ------------------------------
 160
 161 Changes to the Hexagon Backend
 162 ------------------------------
 163
 164 * ...
 165
 166 Changes to the LoongArch Backend
 167 --------------------------------
 168
 169 * The ``lp64s`` ABI is supported now and has been tested on Rust bare-matal target.
 170
 171 Changes to the MIPS Backend
 172 ---------------------------
 173
 174 * ...
 175
 176 Changes to the PowerPC Backend
 177 ------------------------------
 178
 179 * A new option ``-mxcoff-roptr`` is added to ``clang`` and ``llc``. When this
 180   option is present, constant objects with relocatable address values are put
 181   into the RO data section. This option should be used with the ``-fdata-sections``
 182   option, and is not supported with ``-fno-data-sections``. The option is
 183   only supported on AIX.
 184 * On AIX, teach the profile runtime to check for a build-id string; such string
 185   can be created by the -mxcoff-build-id option.
 186
 187 Changes to the RISC-V Backend
 188 -----------------------------
 189
 190 * Assembler support for version 1.0.1 of the Zcb extension was added.
 191 * Zca, Zcf, and Zcd extensions were upgraded to version 1.0.1.
 192 * vsetvli intrinsics no longer have side effects. They may now be combined,
 193   moved, deleted, etc. by optimizations.
 194 * Adds support for the vendor-defined XTHeadBa (address-generation) extension.
 195 * Adds support for the vendor-defined XTHeadBb (basic bit-manipulation) extension.
 196 * Adds support for the vendor-defined XTHeadBs (single-bit) extension.
 197 * Adds support for the vendor-defined XTHeadCondMov (conditional move) extension.
 198 * Adds support for the vendor-defined XTHeadMac (multiply-accumulate instructions) extension.
 199 * Added support for the vendor-defined XTHeadMemPair (two-GPR memory operations)
 200   extension disassembler/assembler.
 201 * Added support for the vendor-defined XTHeadMemIdx (indexed memory operations)
 202   extension disassembler/assembler.
 203 * Added support for the vendor-defined Xsfvcp (SiFive VCIX) extension
 204   disassembler/assembler.
 205 * Support for the now-ratified Zawrs extension is no longer experimental.
 206 * Adds support for the vendor-defined XTHeadCmo (cache management operations) extension.
 207 * Adds support for the vendor-defined XTHeadSync (multi-core synchronization instructions) extension.
 208 * Added support for the vendor-defined XTHeadFMemIdx (indexed memory operations for floating point) extension.
 209 * Assembler support for RV64E was added.
 210 * Assembler support was added for the experimental Zicond (integer conditional
 211   operations) extension.
 212 * I, F, D, and A extension versions have been update to the 20191214 spec versions.
 213   New version I2.1, F2.2, D2.2, A2.1. This should not impact code generation.
 214   Immpacts versions accepted in ``-march`` and reported in ELF attributes.
 215 * Changed the ShadowCallStack register from ``x18`` (``s2``) to ``x3``
 216   (``gp``). Note this breaks the existing non-standard ABI for ShadowCallStack
 217   on RISC-V, but conforms with the new "platform register" defined in the
 218   RISC-V psABI (for more details see the
 219   `psABI discussion <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/370>`_).
 220 * Added support for Zfa extension version 0.2.
 221 * Updated support experimental vector crypto extensions to version 0.5.1 of
 222   the specification.
 223 * Removed N extension (User-Level Interrupts) CSR names in the assembler.
 224 * ``RISCV::parseCPUKind`` and ``RISCV::checkCPUKind`` were merged into a single
 225   ``RISCV::parseCPU``. The ``CPUKind`` enum is no longer part of the
 226   RISCVTargetParser.h interface. Similar for ``parseTuneCPUkind`` and
 227   ``checkTuneCPUKind``.
 228 * Add sifive-x280 processor.
 229 * Zve32f is no longer allowed with Zfinx. Zve64d is no longer allowed with
 230   Zdinx.
 231 * Assembly support was added for the experimental Zfbfmin (scalar BF16
 232   conversions), Zvfbfmin (vector BF16 conversions), and Zvfbfwma (vector BF16
 233   widening mul-add) extensions.
 234
 235 Changes to the WebAssembly Backend
 236 ----------------------------------
 237
 238 * ...
 239
 240 Changes to the Windows Target
 241 -----------------------------
 242
 243 Changes to the X86 Backend
 244 --------------------------
 245
 246 Changes to the OCaml bindings
 247 -----------------------------
 248
 249 Changes to the Python bindings
 250 ------------------------------
 251
 252 * The python bindings have been removed.
 253
 254
 255 Changes to the C API
 256 --------------------
 257
 258 * ``LLVMContextSetOpaquePointers``, a temporary API to pin to legacy typed
 259   pointer, has been removed.
 260 * Functions for adding legacy passes like ``LLVMAddInstructionCombiningPass``
 261   have been removed.
 262 * Removed ``LLVMPassManagerBuilderRef`` and functions interacting with it.
 263   These belonged to the no longer supported legacy pass manager.
 264 * Functions for initializing legacy passes like ``LLVMInitializeInstCombine``
 265   have been removed. Calls to such functions can simply be dropped, as they are
 266   no longer necessary.
 267 * ``LLVMPassRegistryRef`` and ``LLVMGetGlobalPassRegistry``, which were only
 268   useful in conjunction with initialization functions, have been removed.
 269 * As part of the opaque pointer transition, ``LLVMGetElementType`` no longer
 270   gives the pointee type of a pointer type.
 271 * The following functions for creating constant expressions have been removed,
 272   because the underlying constant expressions are no longer supported. Instead,
 273   an instruction should be created using the ``LLVMBuildXYZ`` APIs, which will
 274   constant fold the operands if possible and create an instruction otherwise:
 275
 276   * ``LLVMConstSelect``
 277
 278 Changes to the CodeGen infrastructure
 279 -------------------------------------
 280
 281 * ``llvm.memcpy``, ``llvm.memmove`` and ``llvm.memset`` are now
 282   expanded into loops by default for targets which do not report the
 283   corresponding library function is available.
 284
 285 Changes to the Metadata Info
 286 ---------------------------------
 287
 288 Changes to the Debug Info
 289 ---------------------------------
 290
 291 * The DWARFv5 feature of attaching ``DW_AT_default_value`` to defaulted template
 292   parameters will now be available in any non-strict DWARF mode and in a wider
 293   range of cases than previously.
 294   (`D139953 <https://reviews.llvm.org/D139953>`_,
 295   `D139988 <https://reviews.llvm.org/D139988>`_)
 296
 297 * The ``DW_AT_name`` on ``DW_AT_typedef``\ s for alias templates will now omit
 298   defaulted template parameters. (`D142268 <https://reviews.llvm.org/D142268>`_)
 299
 300 * The experimental ``@llvm.dbg.addr`` intrinsic has been removed (`D144801
 301   <https://reviews.llvm.org/D144801>`_). IR inputs with this intrinsic are
 302   auto-upgraded to ``@llvm.dbg.value`` with ``DW_OP_deref`` appended to the
 303   ``DIExpression`` (`D144793 <https://reviews.llvm.org/D144793>`_).
 304
 305 * When a template class annotated with the ``[[clang::preferred_name]]`` attribute
 306   were to appear in a ``DW_AT_type``, the type will now be that of the preferred_name
 307   instead. This change is only enabled when compiling with `-glldb`.
 308   (`D145803 <https://reviews.llvm.org/D145803>`_)
 309
 310 Changes to the LLVM tools
 311 ---------------------------------
 312 * llvm-lib now supports the /def option for generating a Windows import library from a definition file.
 313
 314 * Made significant changes to JSON output format of `llvm-readobj`/`llvm-readelf`
 315   to improve correctness and clarity.
 316
 317 Changes to LLDB
 318 ---------------------------------
 319
 320 * In the results of commands such as ``expr`` and ``frame var``, type summaries will now
 321   omit defaulted template parameters. The full template parameter list can still be
 322   viewed with ``expr --raw-output``/``frame var --raw-output``. (`D141828 <https://reviews.llvm.org/D141828>`_)
 323
 324 * LLDB is now able to show the subtype of signals found in a core file. For example
 325   memory tagging specific segfaults such as ``SIGSEGV: sync tag check fault``.
 326
 327 * LLDB can now display register fields if they are described in target XML sent
 328   by a debug server such as ``gdbserver`` (``lldb-server`` does not currently produce
 329   this information). Fields are only printed when reading named registers, for
 330   example ``register read cpsr``. They are not shown when reading a register set,
 331   ``register read -s 0``.
 332
 333 Changes to Sanitizers
 334 ---------------------
 335 * For Darwin users that override weak symbols, note that the dynamic linker will
 336   only consider symbols in other mach-o modules which themselves contain at
 337   least one weak symbol. A consequence is that if your program or dylib contains
 338   an intended override of a weak symbol, then it must contain at least one weak
 339   symbol as well for the override to take effect.
 340
 341   Example:
 342
 343   .. code-block:: c
 344
 345     // Add this to make sure your override takes effect
 346     __attribute__((weak,unused)) unsigned __enableOverrides;
 347
 348     // Example override
 349     extern "C" const char *__asan_default_options() { ... }
 350
 351 Other Changes
 352 -------------
 353
 354 * ``llvm::demangle`` now takes a ``std::string_view`` rather than a
 355   ``const std::string&``. Be careful passing temporaries into
 356   ``llvm::demangle`` that don't outlive the expression using
 357   ``llvm::demangle``.
 358
 359 External Open Source Projects Using LLVM 15
 360 ===========================================
 361
 362 * A project...
 363
 364 Additional Information
 365 ======================
 366
 367 A wide variety of additional information is available on the `LLVM web page
 368 <https://llvm.org/>`_, in particular in the `documentation
 369 <https://llvm.org/docs/>`_ section.  The web page also contains versions of the
 370 API documentation which is up-to-date with the Git version of the source
 371 code.  You can access versions of these documents specific to this release by
 372 going into the ``llvm/docs/`` directory in the LLVM tree.
 373
 374 If you have any questions or comments about LLVM, please feel free to contact
 375 us via the `Discourse forums <https://discourse.llvm.org>`_.