2019-07-18 19:51:05 +08:00
|
|
|
=========================
|
2020-07-15 17:40:53 +08:00
|
|
|
LLVM 12.0.0 Release Notes
|
2019-07-18 19:51:05 +08:00
|
|
|
=========================
|
2012-12-10 07:14:26 +08:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
:local:
|
|
|
|
|
|
2013-01-20 11:29:50 +08:00
|
|
|
.. warning::
|
2020-07-15 17:40:53 +08:00
|
|
|
These are in-progress notes for the upcoming LLVM 12 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,
|
2020-07-15 17:40:53 +08:00
|
|
|
release 12.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.
|
|
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
Note that if you are reading this file from a Git checkout or the main
|
2012-12-10 07:14:26 +08:00
|
|
|
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
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
* ...
|
2020-05-23 19:51:43 +08:00
|
|
|
|
2019-11-09 02:05:37 +08:00
|
|
|
|
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
|
|
|
|
2019-12-25 10:12:15 +08:00
|
|
|
|
2016-03-29 14:55:56 +08:00
|
|
|
Changes to the LLVM IR
|
|
|
|
|
----------------------
|
|
|
|
|
|
2020-07-15 17:40:53 +08:00
|
|
|
* ...
|
2020-05-27 16:31:35 +08:00
|
|
|
|
IR: Define byref parameter attribute
This allows tracking the in-memory type of a pointer argument to a
function for ABI purposes. This is essentially a stripped down version
of byval to remove some of the stack-copy implications in its
definition.
This includes the base IR changes, and some tests for places where it
should be treated similarly to byval. Codegen support will be in a
future patch.
My original attempt at solving some of these problems was to repurpose
byval with a different address space from the stack. However, it is
technically permitted for the callee to introduce a write to the
argument, although nothing does this in reality. There is also talk of
removing and replacing the byval attribute, so a new attribute would
need to take its place anyway.
This is intended avoid some optimization issues with the current
handling of aggregate arguments, as well as fixes inflexibilty in how
frontends can specify the kernel ABI. The most honest representation
of the amdgpu_kernel convention is to expose all kernel arguments as
loads from constant memory. Today, these are raw, SSA Argument values
and codegen is responsible for turning these into loads.
Background:
There currently isn't a satisfactory way to represent how arguments
for the amdgpu_kernel calling convention are passed. In reality,
arguments are passed in a single, flat, constant memory buffer
implicitly passed to the function. It is also illegal to call this
function in the IR, and this is only ever invoked by a driver of some
kind.
It does not make sense to have a stack passed parameter in this
context as is implied by byval. It is never valid to write to the
kernel arguments, as this would corrupt the inputs seen by other
dispatches of the kernel. These argumets are also not in the same
address space as the stack, so a copy is needed to an alloca. From a
source C-like language, the kernel parameters are invisible.
Semantically, a copy is always required from the constant argument
memory to a mutable variable.
The current clang calling convention lowering emits raw values,
including aggregates into the function argument list, since using
byval would not make sense. This has some unfortunate consequences for
the optimizer. In the aggregate case, we end up with an aggregate
store to alloca, which both SROA and instcombine turn into a store of
each aggregate field. The optimizer never pieces this back together to
see that this is really just a copy from constant memory, so we end up
stuck with expensive stack usage.
This also means the backend dictates the alignment of arguments, and
arbitrarily picks the LLVM IR ABI type alignment. By allowing an
explicit alignment, frontends can make better decisions. For example,
there's real no advantage to an aligment higher than 4, so a frontend
could choose to compact the argument layout. Similarly, there is a
high penalty to using an alignment lower than 4, so a frontend could
opt into more padding for small arguments.
Another design consideration is when it is appropriate to expose the
fact that these arguments are all really passed in adjacent
memory. Currently we have a late IR optimization pass in codegen to
rewrite the kernel argument values into explicit loads to enable
vectorization. In most programs, unrelated argument loads can be
merged together. However, exposing this property directly from the
frontend has some disadvantages. We still need a way to track the
original argument sizes and alignments to report to the driver. I find
using some side-channel, metadata mechanism to track this
unappealing. If the kernel arguments were exposed as a single buffer
to begin with, alias analysis would be unaware that the padding bits
betewen arguments are meaningless. Another family of problems is there
are still some gaps in replacing all of the available parameter
attributes with metadata equivalents once lowered to loads.
The immediate plan is to start using this new attribute to handle all
aggregate argumets for kernels. Long term, it makes sense to migrate
all kernel arguments, including scalars, to be passed indirectly in
the same manner.
Additional context is in D79744.
2020-06-06 04:58:47 +08:00
|
|
|
* Added the ``byref`` attribute to better represent argument passing
|
|
|
|
|
for the `amdgpu_kernel` calling convention.
|
|
|
|
|
|
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
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
During this release ...
|
2014-08-23 05:57:38 +08:00
|
|
|
|
2014-07-23 20:59:26 +08:00
|
|
|
Changes to the MIPS Target
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2020-01-15 17:02:56 +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
|
|
|
|
2020-01-15 17:02:56 +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
|
|
|
|
2020-01-15 17:02:56 +08:00
|
|
|
During this release ...
|
|
|
|
|
|
2020-07-23 23:24:45 +08:00
|
|
|
* The 'mpx' feature was removed from the backend. It had been removed from clang
|
|
|
|
|
frontend in 10.0. Mention of the 'mpx' feature in an IR file will print a
|
|
|
|
|
message to stderr, but IR should still compile.
|
|
|
|
|
|
2016-01-26 12:29:15 +08:00
|
|
|
Changes to the AMDGPU Target
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2020-07-15 17:40:53 +08:00
|
|
|
During this release ...
|
2019-11-01 14:32:31 +08:00
|
|
|
|
IR: Define byref parameter attribute
This allows tracking the in-memory type of a pointer argument to a
function for ABI purposes. This is essentially a stripped down version
of byval to remove some of the stack-copy implications in its
definition.
This includes the base IR changes, and some tests for places where it
should be treated similarly to byval. Codegen support will be in a
future patch.
My original attempt at solving some of these problems was to repurpose
byval with a different address space from the stack. However, it is
technically permitted for the callee to introduce a write to the
argument, although nothing does this in reality. There is also talk of
removing and replacing the byval attribute, so a new attribute would
need to take its place anyway.
This is intended avoid some optimization issues with the current
handling of aggregate arguments, as well as fixes inflexibilty in how
frontends can specify the kernel ABI. The most honest representation
of the amdgpu_kernel convention is to expose all kernel arguments as
loads from constant memory. Today, these are raw, SSA Argument values
and codegen is responsible for turning these into loads.
Background:
There currently isn't a satisfactory way to represent how arguments
for the amdgpu_kernel calling convention are passed. In reality,
arguments are passed in a single, flat, constant memory buffer
implicitly passed to the function. It is also illegal to call this
function in the IR, and this is only ever invoked by a driver of some
kind.
It does not make sense to have a stack passed parameter in this
context as is implied by byval. It is never valid to write to the
kernel arguments, as this would corrupt the inputs seen by other
dispatches of the kernel. These argumets are also not in the same
address space as the stack, so a copy is needed to an alloca. From a
source C-like language, the kernel parameters are invisible.
Semantically, a copy is always required from the constant argument
memory to a mutable variable.
The current clang calling convention lowering emits raw values,
including aggregates into the function argument list, since using
byval would not make sense. This has some unfortunate consequences for
the optimizer. In the aggregate case, we end up with an aggregate
store to alloca, which both SROA and instcombine turn into a store of
each aggregate field. The optimizer never pieces this back together to
see that this is really just a copy from constant memory, so we end up
stuck with expensive stack usage.
This also means the backend dictates the alignment of arguments, and
arbitrarily picks the LLVM IR ABI type alignment. By allowing an
explicit alignment, frontends can make better decisions. For example,
there's real no advantage to an aligment higher than 4, so a frontend
could choose to compact the argument layout. Similarly, there is a
high penalty to using an alignment lower than 4, so a frontend could
opt into more padding for small arguments.
Another design consideration is when it is appropriate to expose the
fact that these arguments are all really passed in adjacent
memory. Currently we have a late IR optimization pass in codegen to
rewrite the kernel argument values into explicit loads to enable
vectorization. In most programs, unrelated argument loads can be
merged together. However, exposing this property directly from the
frontend has some disadvantages. We still need a way to track the
original argument sizes and alignments to report to the driver. I find
using some side-channel, metadata mechanism to track this
unappealing. If the kernel arguments were exposed as a single buffer
to begin with, alias analysis would be unaware that the padding bits
betewen arguments are meaningless. Another family of problems is there
are still some gaps in replacing all of the available parameter
attributes with metadata equivalents once lowered to loads.
The immediate plan is to start using this new attribute to handle all
aggregate argumets for kernels. Long term, it makes sense to migrate
all kernel arguments, including scalars, to be passed indirectly in
the same manner.
Additional context is in D79744.
2020-06-06 04:58:47 +08:00
|
|
|
* The new ``byref`` attribute is now the preferred method for
|
|
|
|
|
representing aggregate kernel arguments.
|
|
|
|
|
|
2016-11-18 06:26:09 +08:00
|
|
|
Changes to the AVR Target
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2020-07-15 17:40:53 +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
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
2020-07-15 17:40:53 +08:00
|
|
|
During this release ...
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
Changes to the Go bindings
|
|
|
|
|
--------------------------
|
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
|
|
|
|
2020-04-07 18:05:22 +08:00
|
|
|
|
|
|
|
|
Changes to the Debug Info
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
2020-07-15 17:40:53 +08:00
|
|
|
During this release ...
|
2020-04-07 18:05:22 +08:00
|
|
|
|
2020-04-10 16:33:33 +08:00
|
|
|
Changes to the LLVM tools
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
2020-07-20 15:47:11 +08:00
|
|
|
* llvm-readobj and llvm-readelf behavior has changed to report an error when
|
|
|
|
|
executed with no input files instead of reading an input from stdin.
|
|
|
|
|
Reading from stdin can still be achieved by specifying `-` as an input file.
|
2020-06-20 10:06:14 +08:00
|
|
|
|
2019-07-06 01:58:30 +08:00
|
|
|
Changes to LLDB
|
2020-07-17 01:07:12 +08:00
|
|
|
---------------------------------
|
2019-07-06 01:58:30 +08:00
|
|
|
|
2020-07-15 17:40:53 +08:00
|
|
|
External Open Source Projects Using LLVM 12
|
2019-07-18 19:51:05 +08:00
|
|
|
===========================================
|
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
|
2020-01-15 17:02:56 +08:00
|
|
|
API documentation which is up-to-date with the Git version of the source
|
2012-12-10 07:14:26 +08:00
|
|
|
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>`_.
|