docs/ReleaseNotes.rst

   1 ========================
   2 LLVM 9.0.0 Release Notes
   3 ========================
   4
   5 .. contents::
   6     :local:
   7
   8 .. warning::
   9    These are in-progress notes for the upcoming LLVM 9 release.
  10    Release notes for previous releases can be found on
  11    `the Download Page <https://releases.llvm.org/download.html>`_.
  12
  13
  14 Introduction
  15 ============
  16
  17 This document contains the release notes for the LLVM Compiler Infrastructure,
  18 release 9.0.0.  Here we describe the status of LLVM, including major improvements
  19 from the previous release, improvements in various subprojects of LLVM, and
  20 some of the current users of the code.  All LLVM releases may be downloaded
  21 from the `LLVM releases web site <https://llvm.org/releases/>`_.
  22
  23 For more information about LLVM, including information about the latest
  24 release, please check out the `main LLVM web site <https://llvm.org/>`_.  If you
  25 have questions or comments, the `LLVM Developer's Mailing List
  26 <https://lists.llvm.org/mailman/listinfo/llvm-dev>`_ is a good place to send
  27 them.
  28
  29 Note that if you are reading this file from a Subversion checkout or the main
  30 LLVM web page, this document applies to the *next* release, not the current
  31 one.  To see the release notes for a specific release, please see the `releases
  32 page <https://llvm.org/releases/>`_.
  33
  34 Non-comprehensive list of changes in this release
  35 =================================================
  36 .. NOTE
  37    For small 1-3 sentence descriptions, just add an entry at the end of
  38    this list. If your description won't fit comfortably in one bullet
  39    point (e.g. maybe you would like to give an example of the
  40    functionality, or simply have a lot to talk about), see the `NOTE` below
  41    for adding a new subsection.
  42
  43 * The optimizer will now convert calls to ``memcmp`` into a calls to ``bcmp`` in
  44   some circumstances. Users who are building freestanding code (not depending on
  45   the platform's libc) without specifying ``-ffreestanding`` may need to either
  46   pass ``-fno-builtin-bcmp``, or provide a ``bcmp`` function.
  47
  48 * Two new extension points, namely ``EP_FullLinkTimeOptimizationEarly`` and
  49   ``EP_FullLinkTimeOptimizationLast`` are available for plugins to specialize
  50   the legacy pass manager full LTO pipeline.
  51
  52 * **llvm-objcopy/llvm-strip** got support for COFF object files/executables,
  53   supporting the most common copying/stripping options.
  54
  55 * The CMake parameter ``CLANG_ANALYZER_ENABLE_Z3_SOLVER`` has been replaced by
  56   ``LLVM_ENABLE_Z3_SOLVER``.
  57
  58 * The RISCV target is no longer "experimental" (see below for more details).
  59
  60 * The ORCv1 JIT API has been deprecated. Please see
  61   `Transitioning from ORCv1 to ORCv2 <ORCv2.html#transitioning-from-orcv1-to-orcv2>`_.
  62
  63 * Support for target-independent hardware loops in IR has been added, with
  64   PowerPC and Arm implementations.
  65
  66 .. NOTE
  67    If you would like to document a larger change, then you can add a
  68    subsection about it right here. You can copy the following boilerplate
  69    and un-indent it (the indentation causes it to be inside this comment).
  70
  71    Special New Feature
  72    -------------------
  73
  74    Makes programs 10x faster by doing Special New Thing.
  75
  76 Noteworthy optimizations
  77 ------------------------
  78
  79 * LLVM will now remove stores to constant memory (since this is a
  80   contradiction) under the assumption the code in question must be dead.  This
  81   has proven to be problematic for some C/C++ code bases which expect to be
  82   able to cast away 'const'.  This is (and has always been) undefined
  83   behavior, but up until now had not been actively utilized for optimization
  84   purposes in this exact way.  For more information, please see:
  85   `bug 42763 <https://bugs.llvm.org/show_bug.cgi?id=42763>_` and
  86   `post commit discussion <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190422/646945.html>_`.
  87
  88 * LLVM will now pattern match wide scalar values stored by a succession of
  89   narrow stores. For example, Clang will compile the following function that
  90   writes a 32-bit value in big-endian order in a portable manner:
  91
  92   .. code-block:: c
  93
  94       void write32be(unsigned char *dst, uint32_t x) {
  95         dst[0] = x >> 24;
  96         dst[1] = x >> 16;
  97         dst[2] = x >> 8;
  98         dst[3] = x >> 0;
  99       }
 100
 101   into the x86_64 code below:
 102
 103   .. code-block:: asm
 104
 105    write32be:
 106            bswap   esi
 107            mov     dword ptr [rdi], esi
 108            ret
 109
 110   (The corresponding read patterns have been matched since LLVM 5.)
 111
 112 * LLVM will now omit range checks for jump tables when lowering switches with
 113   unreachable default destination. For example, the switch dispatch in the C++
 114   code below
 115
 116   .. code-block:: c
 117
 118      int g(int);
 119      enum e { A, B, C, D, E };
 120      int f(e x, int y, int z) {
 121        switch(x) {
 122          case A: return g(y);
 123          case B: return g(z);
 124          case C: return g(y+z);
 125          case D: return g(x-z);
 126          case E: return g(x+z);
 127        }
 128      }
 129
 130   will result in the following x86_64 machine code when compiled with Clang.
 131   This is because falling off the end of a non-void function is undefined
 132   behaviour in C++, and the end of the function therefore being treated as
 133   unreachable:
 134
 135   .. code-block:: asm
 136
 137    _Z1f1eii:
 138            mov     eax, edi
 139            jmp     qword ptr [8*rax + .LJTI0_0]
 140
 141
 142 * LLVM can now sink similar instructions to a common successor block also when
 143   the instructions have no uses, such as calls to void functions. This allows
 144   code such as
 145
 146   .. code-block:: c
 147
 148    void g(int);
 149    enum e { A, B, C, D };
 150    void f(e x, int y, int z) {
 151      switch(x) {
 152        case A: g(6); break;
 153        case B: g(3); break;
 154        case C: g(9); break;
 155        case D: g(2); break;
 156      }
 157    }
 158
 159   to be optimized to a single call to ``g``, with the argument loaded from a
 160   lookup table.
 161
 162
 163 Changes to the LLVM IR
 164 ----------------------
 165
 166 * Added ``immarg`` parameter attribute. This indicates an intrinsic
 167   parameter is required to be a simple constant. This annotation must
 168   be accurate to avoid possible miscompiles.
 169
 170 * The 2-field form of global variables ``@llvm.global_ctors`` and
 171   ``@llvm.global_dtors`` has been deleted. The third field of their element
 172   type is now mandatory. Specify `i8* null` to migrate from the obsoleted
 173   2-field form.
 174
 175 * The ``byval`` attribute can now take a type parameter:
 176   ``byval(<ty>)``. If present it must be identical to the argument's
 177   pointee type. In the next release we intend to make this parameter
 178   mandatory in preparation for opaque pointer types.
 179
 180 * ``atomicrmw xchg`` now allows floating point types
 181
 182 * ``atomicrmw`` now supports ``fadd`` and ``fsub``
 183
 184 Changes to building LLVM
 185 ------------------------
 186
 187 * Building LLVM with Visual Studio now requires version 2017 or later.
 188
 189
 190 Changes to the AArch64 Backend
 191 ------------------------------
 192
 193 * Assembly-level support was added for: Scalable Vector Extension 2 (SVE2) and
 194   Memory Tagging Extensions (MTE).
 195
 196 Changes to the ARM Backend
 197 --------------------------
 198
 199 * Assembly-level support was added for the Armv8.1-M architecture, including
 200   the M-Profile Vector Extension (MVE).
 201
 202 * A pipeline model was added for Cortex-M4. This pipeline model is also used to
 203   tune for cores where this gives a benefit too: Cortex-M3, SC300, Cortex-M33
 204   and Cortex-M35P.
 205
 206 * Code generation support for M-profile low-overhead loops.
 207
 208
 209 Changes to the MIPS Target
 210 --------------------------
 211
 212 * Support for ``.cplocal`` assembler directive.
 213
 214 * Support for ``sge``, ``sgeu``, ``sgt``, ``sgtu`` pseudo instructions.
 215
 216 * Support for ``o`` inline asm constraint.
 217
 218 * Improved support of GlobalISel instruction selection framework.
 219   This feature is still in experimental state for MIPS targets though.
 220
 221 * Various code-gen improvements, related to improved and fixed instruction
 222   selection and encoding and floating-point registers allocation.
 223
 224 * Complete P5600 scheduling model.
 225
 226
 227 Changes to the PowerPC Target
 228 -----------------------------
 229
 230 * Improved handling of TOC pointer spills for indirect calls
 231
 232 * Improve precision of square root reciprocal estimate
 233
 234 * Enabled MachinePipeliner support for P9 with -ppc-enable-pipeliner.
 235
 236 * MMX/SSE/SSE2 intrinsics headers have been ported to PowerPC using Altivec.
 237
 238 * Machine verification failures cleaned, EXPENSIVE_CHECKS will run
 239   MachineVerification by default now.
 240
 241 * PowerPC scheduling enhancements, with customized PPC specific scheduler
 242   strategy.
 243
 244 * Inner most loop now always align to 32 bytes.
 245
 246 * Enhancements of hardware loops interaction with LSR.
 247
 248 * New builtins added, eg: __builtin_setrnd.
 249
 250 * Various codegen improvements for both scalar and vector code
 251
 252 * Various new exploitations and bug fixes, eg: exploited P9 maddld.
 253
 254
 255 Changes to the SystemZ Target
 256 -----------------------------
 257
 258 * Support for the arch13 architecture has been added.  When using the
 259   ``-march=arch13`` option, the compiler will generate code making use of
 260   new instructions introduced with the vector enhancement facility 2
 261   and the miscellaneous instruction extension facility 2.
 262   The ``-mtune=arch13`` option enables arch13 specific instruction
 263   scheduling and tuning without making use of new instructions.
 264
 265 * Builtins for the new vector instructions have been added and can be
 266   enabled using the ``-mzvector`` option.  Support for these builtins
 267   is indicated by the compiler predefining the ``__VEC__`` macro to
 268   the value ``10303``.
 269
 270 * The compiler now supports and automatically generates alignment hints
 271   on vector load and store instructions.
 272
 273 * Various code-gen improvements, in particular related to improved
 274   instruction selection and register allocation.
 275
 276 Changes to the X86 Target
 277 -------------------------
 278
 279 * Fixed a bug in generating DWARF unwind information for 32 bit MinGW
 280
 281 Changes to the AMDGPU Target
 282 -----------------------------
 283
 284 * Function call support is now enabled by default
 285
 286 * Improved support for 96-bit loads and stores
 287
 288 * DPP combiner pass is now enabled by default
 289
 290 * Support for gfx10
 291
 292 Changes to the AVR Target
 293 -----------------------------
 294
 295  During this release ...
 296
 297 Changes to the WebAssembly Target
 298 ---------------------------------
 299
 300  During this release ...
 301
 302 Changes to the RISCV Target
 303 ---------------------------------
 304
 305 The RISCV target is no longer "experimental"! It's now built by default,
 306 rather than needing to be enabled with ``LLVM_EXPERIMENTAL_TARGETS_TO_BUILD``.
 307
 308 The backend has full codegen support for the RV32I and RV64I base RISC-V
 309 instruction set variants, with the MAFDC standard extensions. We support the
 310 hard and soft-float ABIs for these targets. Testing has been performed with
 311 both Linux and bare-metal targets, including the compilation of a large corpus
 312 of Linux applications (through buildroot).
 313
 314
 315 Changes to the OCaml bindings
 316 -----------------------------
 317
 318
 319
 320 Changes to the C API
 321 --------------------
 322
 323
 324 Changes to the DAG infrastructure
 325 ---------------------------------
 326
 327 Changes to LLDB
 328 ===============
 329
 330 * Backtraces are now color highlighting in the terminal.
 331
 332 * DWARF4 (debug_types) and DWARF5 (debug_info) type units are now supported.
 333
 334 * This release will be the last where ``lldb-mi`` is shipped as part of LLDB.
 335   The tool will still be available in a `downstream repository on GitHub
 336   <https://github.com/lldb-tools/lldb-mi>`_.
 337
 338 External Open Source Projects Using LLVM 9
 339 ==========================================
 340
 341 Mull - Mutation Testing tool for C and C++
 342 ------------------------------------------
 343
 344 `Mull <https://github.com/mull-project/mull>`_ is a LLVM-based tool for
 345 mutation testing with a strong focus on C and C++ languages.
 346
 347 Zig Programming Language
 348 ------------------------
 349
 350 `Zig <https://ziglang.org>`_  is a system programming language intended to be
 351 an alternative to C. It provides high level features such as generics, compile
 352 time function execution, and partial evaluation, while exposing low level LLVM
 353 IR features such as aliases and intrinsics. Zig uses Clang to provide automatic
 354 import of .h symbols, including inline functions and simple macros. Zig uses
 355 LLD combined with lazily building compiler-rt to provide out-of-the-box
 356 cross-compiling for all supported targets.
 357
 358
 359
 360 Additional Information
 361 ======================
 362
 363 A wide variety of additional information is available on the `LLVM web page
 364 <https://llvm.org/>`_, in particular in the `documentation
 365 <https://llvm.org/docs/>`_ section.  The web page also contains versions of the
 366 API documentation which is up-to-date with the Subversion version of the source
 367 code.  You can access versions of these documents specific to this release by
 368 going into the ``llvm/docs/`` directory in the LLVM tree.
 369
 370 If you have any questions or comments about LLVM, please feel free to contact
 371 us via the `mailing lists <https://llvm.org/docs/#mailing-lists>`_.