2019-07-18 19:51:05 +08:00
|
|
|
=========================
|
|
|
|
|
LLVM 10.0.0 Release Notes
|
|
|
|
|
=========================
|
2012-12-10 07:14:26 +08:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
:local:
|
|
|
|
|
|
2013-01-20 11:29:50 +08:00
|
|
|
.. warning::
|
2019-07-18 19:51:05 +08:00
|
|
|
These are in-progress notes for the upcoming LLVM 10 release.
|
2017-02-10 07:03:34 +08:00
|
|
|
Release notes for previous releases can be found on
|
2018-09-10 16:50:31 +08:00
|
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
2012-12-10 07:14:26 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
This document contains the release notes for the LLVM Compiler Infrastructure,
|
2019-07-18 19:51:05 +08:00
|
|
|
release 10.0.0. Here we describe the status of LLVM, including major improvements
|
2012-12-10 07:14:26 +08:00
|
|
|
from the previous release, improvements in various subprojects of LLVM, and
|
|
|
|
|
some of the current users of the code. All LLVM releases may be downloaded
|
2018-09-10 16:50:31 +08:00
|
|
|
from the `LLVM releases web site <https://llvm.org/releases/>`_.
|
2012-12-10 07:14:26 +08:00
|
|
|
|
|
|
|
|
For more information about LLVM, including information about the latest
|
2018-09-10 16:50:31 +08:00
|
|
|
release, please check out the `main LLVM web site <https://llvm.org/>`_. If you
|
2012-12-10 07:14:26 +08:00
|
|
|
have questions or comments, the `LLVM Developer's Mailing List
|
2018-09-10 16:50:31 +08:00
|
|
|
<https://lists.llvm.org/mailman/listinfo/llvm-dev>`_ is a good place to send
|
2012-12-10 07:14:26 +08:00
|
|
|
them.
|
|
|
|
|
|
|
|
|
|
Note that if you are reading this file from a Subversion checkout or the main
|
|
|
|
|
LLVM web page, this document applies to the *next* release, not the current
|
|
|
|
|
one. To see the release notes for a specific release, please see the `releases
|
2018-09-10 16:50:31 +08:00
|
|
|
page <https://llvm.org/releases/>`_.
|
2012-12-10 07:14:26 +08:00
|
|
|
|
2013-01-20 11:29:50 +08:00
|
|
|
Non-comprehensive list of changes in this release
|
|
|
|
|
=================================================
|
|
|
|
|
.. NOTE
|
|
|
|
|
For small 1-3 sentence descriptions, just add an entry at the end of
|
|
|
|
|
this list. If your description won't fit comfortably in one bullet
|
|
|
|
|
point (e.g. maybe you would like to give an example of the
|
|
|
|
|
functionality, or simply have a lot to talk about), see the `NOTE` below
|
|
|
|
|
for adding a new subsection.
|
2012-12-10 07:14:26 +08:00
|
|
|
|
2019-09-10 01:54:44 +08:00
|
|
|
* The ISD::FP_ROUND_INREG opcode and related code was removed from SelectionDAG.
|
2019-10-17 05:52:09 +08:00
|
|
|
* Enabled MemorySSA as a loop dependency. Since
|
|
|
|
|
`r370957 <https://reviews.llvm.org/rL370957>`_
|
|
|
|
|
(`D58311 <https://reviews.llvm.org/D58311>`_ ``[MemorySSA & LoopPassManager]
|
|
|
|
|
Enable MemorySSA as loop dependency. Update tests.``), the MemorySSA analysis
|
|
|
|
|
is being preserved and used by a series of loop passes. The most significant
|
|
|
|
|
use is in LICM, where the instruction hoisting and sinking relies on aliasing
|
|
|
|
|
information provided by MemorySSA vs previously creating an AliasSetTracker.
|
|
|
|
|
The LICM step of promoting variables to scalars still relies on the creation
|
|
|
|
|
of an AliasSetTracker, but its use is reduced to only be enabled for loops
|
|
|
|
|
with a small number of overall memory instructions. This choice was motivated
|
|
|
|
|
by experimental results showing compile and run time benefits or replacing the
|
|
|
|
|
AliasSetTracker usage with MemorySSA without any performance penalties.
|
|
|
|
|
The fact that MemorySSA is now preserved by and available in a series of loop
|
|
|
|
|
passes, also opens up opportunities for its use in those respective passes.
|
2019-10-31 04:39:11 +08:00
|
|
|
* The BasicBlockPass, BBPassManager and all their uses were deleted in
|
|
|
|
|
`this revision <https://reviews.llvm.org/rG9f0ff0b2634bab6a5be8dace005c9eb24d386dd1>`_.
|
2019-09-10 01:54:44 +08:00
|
|
|
|
2019-11-09 02:05:37 +08:00
|
|
|
* The LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB CMake options are no longer
|
|
|
|
|
available on Windows.
|
|
|
|
|
|
2013-01-20 11:29:50 +08:00
|
|
|
.. NOTE
|
|
|
|
|
If you would like to document a larger change, then you can add a
|
|
|
|
|
subsection about it right here. You can copy the following boilerplate
|
|
|
|
|
and un-indent it (the indentation causes it to be inside this comment).
|
2012-12-10 07:14:26 +08:00
|
|
|
|
2013-01-20 11:29:50 +08:00
|
|
|
Special New Feature
|
|
|
|
|
-------------------
|
2012-12-10 07:14:26 +08:00
|
|
|
|
2013-01-20 11:29:50 +08:00
|
|
|
Makes programs 10x faster by doing Special New Thing.
|
2012-12-10 07:14:26 +08:00
|
|
|
|
[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour
Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4 When an expression J that has integral type is added to or subtracted
from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
elements ([dcl.array]), the expressions P + J and J + P
(where J has the value j) point to the (possibly-hypothetical) array
element i+j of x if 0≤i+j≤n and the expression P - J points to the
(possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```
Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)
To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".
Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566
Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.
`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown
Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers
Reviewed By: rsmith
Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits
Tags: #clang, #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D67122
llvm-svn: 374293
2019-10-10 17:25:02 +08:00
|
|
|
* As per :ref:`LLVM Language Reference Manual <i_getelementptr>`,
|
|
|
|
|
``getelementptr inbounds`` can not change the null status of a pointer,
|
|
|
|
|
meaning it can not produce non-null pointer given null base pointer, and
|
|
|
|
|
likewise given non-null base pointer it can not produce null pointer; if it
|
|
|
|
|
does, the result is a :ref:`poison value <poisonvalues>`.
|
|
|
|
|
Since `r369789 <https://reviews.llvm.org/rL369789>`_
|
|
|
|
|
(`D66608 <https://reviews.llvm.org/D66608>`_ ``[InstCombine] icmp eq/ne (gep
|
|
|
|
|
inbounds P, Idx..), null -> icmp eq/ne P, null``) LLVM uses that for
|
|
|
|
|
transformations. If the original source violates these requirements this
|
|
|
|
|
may result in code being miscompiled. If you are using Clang front-end,
|
|
|
|
|
Undefined Behaviour Sanitizer ``-fsanitize=pointer-overflow`` check
|
|
|
|
|
will now catch such cases.
|
|
|
|
|
|
|
|
|
|
|
Add Windows Control Flow Guard checks (/guard:cf).
Summary:
A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on
indirect function calls, using either the check mechanism (X86, ARM, AArch64) or
or the dispatch mechanism (X86-64). The check mechanism requires a new calling
convention for the supported targets. The dispatch mechanism adds the target as
an operand bundle, which is processed by SelectionDAG. Another pass
(CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as
required by /guard:cf. This feature is enabled using the `cfguard` CC1 option.
Reviewers: thakis, rnk, theraven, pcc
Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D65761
2019-10-28 21:22:19 +08:00
|
|
|
* Windows Control Flow Guard: the ``-cfguard`` option now emits CFG checks on
|
|
|
|
|
indirect function calls. The previous behavior is still available with the
|
|
|
|
|
``-cfguard-nochecks`` option. Note that this feature should always be used
|
|
|
|
|
with optimizations enabled.
|
|
|
|
|
|
2019-12-07 06:40:21 +08:00
|
|
|
* ``Callbacks`` have been added to ``CommandLine Options``. These can
|
|
|
|
|
be used to validate of selectively enable other options.
|
|
|
|
|
|
2019-12-25 10:12:15 +08:00
|
|
|
* The function attributes ``no-frame-pointer-elim`` and
|
|
|
|
|
``no-frame-pointer-elim-non-leaf`` have been replaced by ``frame-pointer``,
|
|
|
|
|
which has 3 values: ``none``, ``non-leaf``, and ``all``. The values mean what
|
|
|
|
|
functions should retain frame pointers.
|
|
|
|
|
|
2016-03-29 14:55:56 +08:00
|
|
|
Changes to the LLVM IR
|
|
|
|
|
----------------------
|
|
|
|
|
|
2019-08-03 22:28:34 +08:00
|
|
|
* Unnamed function arguments now get printed with their automatically
|
|
|
|
|
generated name (e.g. "i32 %0") in definitions. This may require front-ends
|
|
|
|
|
to update their tests; if so there is a script utils/add_argument_names.py
|
|
|
|
|
that correctly converted 80-90% of Clang tests. Some manual work will almost
|
|
|
|
|
certainly still be needed.
|
|
|
|
|
|
|
|
|
|
|
2019-07-09 18:10:48 +08:00
|
|
|
Changes to building LLVM
|
|
|
|
|
------------------------
|
|
|
|
|
|
2014-03-18 18:16:15 +08:00
|
|
|
Changes to the ARM Backend
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2014-08-23 05:57:38 +08:00
|
|
|
During this release ...
|
|
|
|
|
|
2014-03-18 18:16:15 +08:00
|
|
|
|
2014-07-23 20:59:26 +08:00
|
|
|
Changes to the MIPS Target
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2015-01-15 02:07:30 +08:00
|
|
|
During this release ...
|
2015-01-11 18:34:52 +08:00
|
|
|
|
2014-07-23 20:59:26 +08:00
|
|
|
|
2014-07-31 22:38:17 +08:00
|
|
|
Changes to the PowerPC Target
|
2014-07-31 23:20:30 +08:00
|
|
|
-----------------------------
|
2014-07-31 22:38:17 +08:00
|
|
|
|
2016-07-19 02:02:23 +08:00
|
|
|
During this release ...
|
2014-07-31 22:38:17 +08:00
|
|
|
|
2015-12-21 10:37:23 +08:00
|
|
|
Changes to the X86 Target
|
2016-03-29 14:55:56 +08:00
|
|
|
-------------------------
|
2015-12-21 10:37:23 +08:00
|
|
|
|
2019-01-16 18:57:02 +08:00
|
|
|
During this release ...
|
2015-12-21 10:37:23 +08:00
|
|
|
|
2019-08-29 01:18:56 +08:00
|
|
|
* Less than 128 bit vector types, v2i32, v4i16, v2i16, v8i8, v4i8, and v2i8, are
|
|
|
|
|
now stored in the lower bits of an xmm register and the upper bits are
|
|
|
|
|
undefined. Previously the elements were spread apart with undefined bits in
|
|
|
|
|
between them.
|
2019-08-31 01:35:08 +08:00
|
|
|
* v32i8 and v64i8 vectors with AVX512F enabled, but AVX512BW disabled will now
|
|
|
|
|
be passed in ZMM registers for calls and returns. Previously they were passed
|
|
|
|
|
in two YMM registers. Old behavior can be enabled by passing
|
|
|
|
|
-x86-enable-old-knl-abi
|
2019-09-12 07:54:36 +08:00
|
|
|
* -mprefer-vector-width=256 is now the default behavior skylake-avx512 and later
|
|
|
|
|
Intel CPUs. This tries to limit the use of 512-bit registers which can cause a
|
|
|
|
|
decrease in CPU frequency on these CPUs. This can be re-enabled by passing
|
|
|
|
|
-mprefer-vector-width=512 to clang or passing -mattr=-prefer-256-bit to llc.
|
2019-11-05 02:20:00 +08:00
|
|
|
* Deprecated the mpx feature flag for the Intel MPX instructions. There were no
|
|
|
|
|
intrinsics for this feature. This change only this effects the results
|
|
|
|
|
returned by getHostCPUFeatures on CPUs that implement the MPX instructions.
|
|
|
|
|
* The feature flag fast-partial-ymm-or-zmm-write which previously disabled
|
|
|
|
|
vzeroupper insertion has been removed. It has been replaced with a vzeroupper
|
|
|
|
|
feature flag which has the opposite polarity. So -vzeroupper has the same
|
|
|
|
|
effect as +fast-partial-ymm-or-zmm-write.
|
2019-08-29 01:18:56 +08:00
|
|
|
|
2016-01-26 12:29:15 +08:00
|
|
|
Changes to the AMDGPU Target
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2016-11-18 06:26:09 +08:00
|
|
|
Changes to the AVR Target
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2017-01-13 05:50:22 +08:00
|
|
|
During this release ...
|
2016-11-18 06:26:09 +08:00
|
|
|
|
2019-01-15 02:20:30 +08:00
|
|
|
Changes to the WebAssembly Target
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
2019-01-16 18:57:02 +08:00
|
|
|
During this release ...
|
2019-01-16 01:54:42 +08:00
|
|
|
|
2019-01-15 02:20:30 +08:00
|
|
|
|
2015-01-13 17:48:02 +08:00
|
|
|
Changes to the OCaml bindings
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
|
|
|
|
|
2016-02-18 03:35:47 +08:00
|
|
|
|
2017-06-30 09:17:45 +08:00
|
|
|
Changes to the C API
|
|
|
|
|
--------------------
|
2019-12-03 11:59:54 +08:00
|
|
|
* C DebugInfo API ``LLVMDIBuilderCreateTypedef`` is updated to include an extra
|
2019-12-24 04:52:39 +08:00
|
|
|
argument ``AlignInBits``, to facilitate / propagate specified Alignment information
|
|
|
|
|
present in a ``typedef`` to Debug information in LLVM IR.
|
2019-12-03 11:59:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Changes to the Go bindings
|
|
|
|
|
--------------------------
|
|
|
|
|
* Go DebugInfo API ``CreateTypedef`` is updated to include an extra argument ``AlignInBits``,
|
2019-12-24 04:52:39 +08:00
|
|
|
to facilitate / propagate specified Alignment information present in a ``typedef``
|
|
|
|
|
to Debug information in LLVM IR.
|
2017-06-30 09:17:45 +08:00
|
|
|
|
2017-06-30 15:09:08 +08:00
|
|
|
|
Set ADDE/ADDC/SUBE/SUBC to expand by default
Summary:
They've been deprecated in favor of UADDO/ADDCARRY or USUBO/SUBCARRY for a while.
Target that uses these opcodes are changed in order to ensure their behavior doesn't change.
Reviewers: efriedma, craig.topper, dblaikie, bkramer
Subscribers: jholewinski, arsenm, jyknight, sdardis, nemanjai, nhaehnle, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, mgrang, atanasyan, llvm-commits
Differential Revision: https://reviews.llvm.org/D47422
llvm-svn: 333748
2018-06-01 21:21:33 +08:00
|
|
|
Changes to the DAG infrastructure
|
|
|
|
|
---------------------------------
|
2018-06-05 02:36:22 +08:00
|
|
|
|
2019-07-06 01:58:30 +08:00
|
|
|
Changes to LLDB
|
|
|
|
|
===============
|
|
|
|
|
|
2019-07-18 19:51:05 +08:00
|
|
|
External Open Source Projects Using LLVM 10
|
|
|
|
|
===========================================
|
2015-01-13 17:48:02 +08:00
|
|
|
|
2016-07-19 02:02:23 +08:00
|
|
|
* A project...
|
2013-11-14 13:57:40 +08:00
|
|
|
|
|
|
|
|
|
2012-12-10 07:14:26 +08:00
|
|
|
Additional Information
|
|
|
|
|
======================
|
|
|
|
|
|
|
|
|
|
A wide variety of additional information is available on the `LLVM web page
|
2018-09-10 16:50:31 +08:00
|
|
|
<https://llvm.org/>`_, in particular in the `documentation
|
|
|
|
|
<https://llvm.org/docs/>`_ section. The web page also contains versions of the
|
2012-12-10 07:14:26 +08:00
|
|
|
API documentation which is up-to-date with the Subversion version of the source
|
|
|
|
|
code. You can access versions of these documents specific to this release by
|
|
|
|
|
going into the ``llvm/docs/`` directory in the LLVM tree.
|
|
|
|
|
|
|
|
|
|
If you have any questions or comments about LLVM, please feel free to contact
|
2018-09-10 16:50:31 +08:00
|
|
|
us via the `mailing lists <https://llvm.org/docs/#mailing-lists>`_.
|