diff options
Diffstat (limited to 'gnu/llvm/docs')
| -rw-r--r-- | gnu/llvm/docs/Extensions.rst | 2 | ||||
| -rw-r--r-- | gnu/llvm/docs/LangRef.rst | 2 | ||||
| -rw-r--r-- | gnu/llvm/docs/ReleaseNotes.rst | 342 | ||||
| -rw-r--r-- | gnu/llvm/docs/conf.py | 4 |
4 files changed, 280 insertions, 70 deletions
diff --git a/gnu/llvm/docs/Extensions.rst b/gnu/llvm/docs/Extensions.rst index 850c4275091..2b12123cdf6 100644 --- a/gnu/llvm/docs/Extensions.rst +++ b/gnu/llvm/docs/Extensions.rst @@ -61,7 +61,7 @@ types ``IMAGE_REL_I386_SECREL`` (32-bit) or ``IMAGE_REL_AMD64_SECREL`` (64-bit). the target. It corresponds to the COFF relocation types ``IMAGE_REL_I386_SECTION`` (32-bit) or ``IMAGE_REL_AMD64_SECTION`` (64-bit). -.. code-block:: gas +.. code-block:: none .section .debug$S,"rn" .long 4 diff --git a/gnu/llvm/docs/LangRef.rst b/gnu/llvm/docs/LangRef.rst index 5ac17015953..e93a02f6b02 100644 --- a/gnu/llvm/docs/LangRef.rst +++ b/gnu/llvm/docs/LangRef.rst @@ -3997,7 +3997,7 @@ DIFile ``DIFile`` nodes represent files. The ``filename:`` can include slashes. -.. code-block:: llvm +.. code-block:: none !0 = !DIFile(filename: "path/to/file", directory: "/path/to/dir", checksumkind: CSK_MD5, diff --git a/gnu/llvm/docs/ReleaseNotes.rst b/gnu/llvm/docs/ReleaseNotes.rst index dcb742e18c6..573fcb822ab 100644 --- a/gnu/llvm/docs/ReleaseNotes.rst +++ b/gnu/llvm/docs/ReleaseNotes.rst @@ -5,12 +5,6 @@ LLVM 4.0.0 Release Notes .. contents:: :local: -.. warning:: - These are in-progress notes for the upcoming LLVM 4.0.0 release. You may - prefer the `LLVM 3.9 Release Notes <http://llvm.org/releases/3.9.0/docs - /ReleaseNotes.html>`_. - - Introduction ============ @@ -26,91 +20,266 @@ have questions or comments, the `LLVM Developer's Mailing List <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ is a good place to send them. +New Versioning Scheme +===================== +Starting with this release, LLVM is using a +`new versioning scheme <http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html>`_, +increasing the major version number with each major release. Stable updates to +this release will be versioned 4.0.x, and the next major release, six months +from now, will be version 5.0.0. + Non-comprehensive list of changes in this release ================================================= -* The C API functions LLVMAddFunctionAttr, LLVMGetFunctionAttr, - LLVMRemoveFunctionAttr, LLVMAddAttribute, LLVMRemoveAttribute, - LLVMGetAttribute, LLVMAddInstrAttribute and - LLVMRemoveInstrAttribute have been removed. +* The minimum compiler version required for building LLVM has been raised to + 4.8 for GCC and 2015 for Visual Studio. -* The C API enum LLVMAttribute has been deleted. +* The C API functions ``LLVMAddFunctionAttr``, ``LLVMGetFunctionAttr``, + ``LLVMRemoveFunctionAttr``, ``LLVMAddAttribute``, ``LLVMRemoveAttribute``, + ``LLVMGetAttribute``, ``LLVMAddInstrAttribute`` and + ``LLVMRemoveInstrAttribute`` have been removed. -.. 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. +* The C API enum ``LLVMAttribute`` has been deleted. -* The definition and uses of LLVM_ATRIBUTE_UNUSED_RESULT in the LLVM source - were replaced with LLVM_NODISCARD, which matches the C++17 [[nodiscard]] - semantics rather than gcc's __attribute__((warn_unused_result)). - -* Minimum compiler version to build has been raised to GCC 4.8 and VS 2015. +* The definition and uses of ``LLVM_ATRIBUTE_UNUSED_RESULT`` in the LLVM source + were replaced with ``LLVM_NODISCARD``, which matches the C++17 ``[[nodiscard]]`` + semantics rather than gcc's ``__attribute__((warn_unused_result))``. * The Timer related APIs now expect a Name and Description. When upgrading code the previously used names should become descriptions and a short name in the style of a programming language identifier should be added. -* LLVM now handles invariant.group across different basic blocks, which makes +* LLVM now handles ``invariant.group`` across different basic blocks, which makes it possible to devirtualize virtual calls inside loops. -* ... next change ... - -.. 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). - - Special New Feature - ------------------- - - Makes programs 10x faster by doing Special New Thing. - - Improvements to ThinLTO (-flto=thin) - ------------------------------------ - * Integration with profile data (PGO). When available, profile data - enables more accurate function importing decisions, as well as - cross-module indirect call promotion. - * Significant build-time and binary-size improvements when compiling with - debug info (-g). - -Changes to the LLVM IR ----------------------- - -Changes to the ARM Backend +* The aggressive dead code elimination phase ("adce") now removes + branches which do not effect program behavior. Loops are retained by + default since they may be infinite but these can also be removed + with LLVM option ``-adce-remove-loops`` when the loop body otherwise has + no live operations. + +* The llvm-cov tool can now export coverage data as json. Its html output mode + has also improved. + +Improvements to ThinLTO (-flto=thin) +------------------------------------ +Integration with profile data (PGO). When available, profile data +enables more accurate function importing decisions, as well as +cross-module indirect call promotion. + +Significant build-time and binary-size improvements when compiling with +debug info (-g). + +LLVM Coroutines +--------------- + +Experimental support for :doc:`Coroutines` was added, which can be enabled +with ``-enable-coroutines`` in ``opt`` the command tool or using the +``addCoroutinePassesToExtensionPoints`` API when building the optimization +pipeline. + +For more information on LLVM Coroutines and the LLVM implementation, see +`2016 LLVM Developers’ Meeting talk on LLVM Coroutines +<http://llvm.org/devmtg/2016-11/#talk4>`_. + +Regcall and Vectorcall Calling Conventions +-------------------------------------------------- + +Support was added for ``_regcall`` calling convention. +Existing ``__vectorcall`` calling convention support was extended to include +correct handling of HVAs. + +The ``__vectorcall`` calling convention was introduced by Microsoft to +enhance register usage when passing parameters. +For more information please read `__vectorcall documentation +<https://msdn.microsoft.com/en-us/library/dn375768.aspx>`_. + +The ``__regcall`` calling convention was introduced by Intel to +optimize parameter transfer on function call. +This calling convention ensures that as many values as possible are +passed or returned in registers. +For more information please read `__regcall documentation +<https://software.intel.com/en-us/node/693069>`_. + +Code Generation Testing +----------------------- + +Passes that work on the machine instruction representation can be tested with +the .mir serialization format. ``llc`` supports the ``-run-pass``, +``-stop-after``, ``-stop-before``, ``-start-after``, ``-start-before`` to +run a single pass of the code generation pipeline, or to stop or start the code +generation pipeline at a given point. + +Additional information can be found in the :doc:`MIRLangRef`. The format is +used by the tests ending in ``.mir`` in the ``test/CodeGen`` directory. + +This feature is available since 2015. It is used more often lately and was not +mentioned in the release notes yet. + +Intrusive list API overhaul +--------------------------- + +The intrusive list infrastructure was substantially rewritten over the last +couple of releases, primarily to excise undefined behaviour. The biggest +changes landed in this release. + +* ``simple_ilist<T>`` is a lower-level intrusive list that never takes + ownership of its nodes. New intrusive-list clients should consider using it + instead of ``ilist<T>``. + + * ``ilist_tag<class>`` allows a single data type to be inserted into two + parallel intrusive lists. A type can inherit twice from ``ilist_node``, + first using ``ilist_node<T,ilist_tag<A>>`` (enabling insertion into + ``simple_ilist<T,ilist_tag<A>>``) and second using + ``ilist_node<T,ilist_tag<B>>`` (enabling insertion into + ``simple_ilist<T,ilist_tag<B>>``), where ``A`` and ``B`` are arbitrary + types. + + * ``ilist_sentinel_tracking<bool>`` controls whether an iterator knows + whether it's pointing at the sentinel (``end()``). By default, sentinel + tracking is on when ABI-breaking checks are enabled, and off otherwise; + this is used for an assertion when dereferencing ``end()`` (this assertion + triggered often in practice, and many backend bugs were fixed). Explicitly + turning on sentinel tracking also enables ``iterator::isEnd()``. This is + used by ``MachineInstrBundleIterator`` to iterate over bundles. + +* ``ilist<T>`` is built on top of ``simple_ilist<T>``, and supports the same + configuration options. As before (and unlike ``simple_ilist<T>``), + ``ilist<T>`` takes ownership of its nodes. However, it no longer supports + *allocating* nodes, and is now equivalent to ``iplist<T>``. ``iplist<T>`` + will likely be removed in the future. + + * ``ilist<T>`` now always uses ``ilist_traits<T>``. Instead of passing a + custom traits class in via a template parameter, clients that want to + customize the traits should specialize ``ilist_traits<T>``. Clients that + want to avoid ownership can specialize ``ilist_alloc_traits<T>`` to inherit + from ``ilist_noalloc_traits<T>`` (or to do something funky); clients that + need callbacks can specialize ``ilist_callback_traits<T>`` directly. + +* The underlying data structure is now a simple recursive linked list. The + sentinel node contains only a "next" (``begin()``) and "prev" (``rbegin()``) + pointer and is stored in the same allocation as ``simple_ilist<T>``. + Previously, it was malloc-allocated on-demand by default, although the + now-defunct ``ilist_sentinel_traits<T>`` was sometimes specialized to avoid + this. + +* The ``reverse_iterator`` class no longer uses ``std::reverse_iterator``. + Instead, it now has a handle to the same node that it dereferences to. + Reverse iterators now have the same iterator invalidation semantics as + forward iterators. + + * ``iterator`` and ``reverse_iterator`` have explicit conversion constructors + that match ``std::reverse_iterator``'s off-by-one semantics, so that + reversing the end points of an iterator range results in the same range + (albeit in reverse). I.e., ``reverse_iterator(begin())`` equals + ``rend()``. + + * ``iterator::getReverse()`` and ``reverse_iterator::getReverse()`` return an + iterator that dereferences to the *same* node. I.e., + ``begin().getReverse()`` equals ``--rend()``. + + * ``ilist_node<T>::getIterator()`` and + ``ilist_node<T>::getReverseIterator()`` return the forward and reverse + iterators that dereference to the current node. I.e., + ``begin()->getIterator()`` equals ``begin()`` and + ``rbegin()->getReverseIterator()`` equals ``rbegin()``. + +* ``iterator`` now stores an ``ilist_node_base*`` instead of a ``T*``. The + implicit conversions between ``ilist<T>::iterator`` and ``T*`` have been + removed. Clients may use ``N->getIterator()`` (if not ``nullptr``) or + ``&*I`` (if not ``end()``); alternatively, clients may refactor to use + references for known-good nodes. + +Changes to the ARM Targets -------------------------- - During this release ... +**During this release the AArch64 target has:** + +* Gained support for ILP32 relocations. +* Gained support for XRay. +* Made even more progress on GlobalISel. There is still some work left before + it is production-ready though. +* Refined the support for Qualcomm's Falkor and Samsung's Exynos CPUs. +* Learned a few new tricks for lowering multiplications by constants, folding + spilled/refilled copies etc. + +**During this release the ARM target has:** + +* Gained support for ROPI (read-only position independence) and RWPI + (read-write position independence), which can be used to remove the need for + a dynamic linker. +* Gained support for execute-only code, which is placed in pages without read + permissions. +* Gained a machine scheduler for Cortex-R52. +* Gained support for XRay. +* Gained Thumb1 implementations for several compiler-rt builtins. It also + has some support for building the builtins for HF targets. +* Started using the generic bitreverse intrinsic instead of rbit. +* Gained very basic support for GlobalISel. + +A lot of work has also been done in LLD for ARM, which now supports more +relocations and TLS. + +Note: From the next release (5.0), the "vulcan" target will be renamed to +"thunderx2t99", including command line options, assembly directives, etc. This +release (4.0) will be the last one to accept "vulcan" as its name. +Changes to the AVR Target +----------------------------- -Changes to the MIPS Target --------------------------- +This marks the first release where the AVR backend has been completely merged +from a fork into LLVM trunk. The backend is still marked experimental, but +is generally quite usable. All downstream development has halted on +`GitHub <https://github.com/avr-llvm/llvm>`_, and changes now go directly into +LLVM trunk. - During this release ... +* Instruction selector and pseudo instruction expansion pass landed +* `read_register` and `write_register` intrinsics are now supported +* Support stack stores greater than 63-bytes from the bottom of the stack +* A number of assertion errors have been fixed +* Support stores to `undef` locations +* Very basic support for the target has been added to clang +* Small optimizations to some 16-bit boolean expressions +Most of the work behind the scenes has been on correctness of generated +assembly, and also fixing some assertions we would hit on some well-formed +inputs. -Changes to the PowerPC Target +Changes to the MIPS Target ----------------------------- - During this release ... +**During this release the MIPS target has:** + +* IAS is now enabled by default for Debian mips64el. +* Added support for the two operand form for many instructions. +* Added the following macros: unaligned load/store, seq, double word load/store for O32. +* Improved the parsing of complex memory offset expressions. +* Enabled the integrated assembler by default for Debian mips64el. +* Added a generic scheduler based on the interAptiv CPU. +* Added support for thread local relocations. +* Added recip, rsqrt, evp, dvp, synci instructions in IAS. +* Optimized the generation of constants from some cases. + +**The following issues have been fixed:** + +* Thread local debug information is correctly recorded. +* MSA intrinsics are now range checked. +* Fixed an issue with MSA and the no-odd-spreg abi. +* Fixed some corner cases in handling forbidden slots for MIPSR6. +* Fixed an issue with jumps not being converted to relative branches for assembly. +* Fixed the handling of local symbols and jal instruction. +* N32/N64 no longer have their relocation tables sorted as per their ABIs. +* Fixed a crash when half-precision floating point conversion MSA intrinsics are used. +* Fixed several crashes involving FastISel. +* Corrected the corrected definitions for aui/daui/dahi/dati for MIPSR6. Changes to the X86 Target ------------------------- - During this release ... - -Changes to the AMDGPU Target ------------------------------ - - During this release ... - -Changes to the AVR Target ------------------------------ +**During this release the X86 target has:** -* The entire backend has been merged in-tree with all tests passing. All of - the instruction selection code and the machine code backend has landed - recently and is fully usable. +* Added support AMD Ryzen (znver1) CPUs. +* Gained support for using VEX encoding on AVX-512 CPUs to reduce code size when possible. +* Improved AVX-512 codegen. Changes to the OCaml bindings ----------------------------- @@ -122,7 +291,48 @@ Changes to the OCaml bindings External Open Source Projects Using LLVM 4.0.0 ============================================== -* A project... +LDC - the LLVM-based D compiler +------------------------------- + +`D <http://dlang.org>`_ is a language with C-like syntax and static typing. It +pragmatically combines efficiency, control, and modeling power, with safety and +programmer productivity. D supports powerful concepts like Compile-Time Function +Execution (CTFE) and Template Meta-Programming, provides an innovative approach +to concurrency and offers many classical paradigms. + +`LDC <http://wiki.dlang.org/LDC>`_ uses the frontend from the reference compiler +combined with LLVM as backend to produce efficient native code. LDC targets +x86/x86_64 systems like Linux, OS X, FreeBSD and Windows and also Linux on ARM +and PowerPC (32/64 bit). Ports to other architectures like AArch64 and MIPS64 +are underway. + +Portable Computing Language (pocl) +---------------------------------- + +In addition to producing an easily portable open source OpenCL +implementation, another major goal of `pocl <http://pocl.sourceforge.net/>`_ +is improving performance portability of OpenCL programs with +compiler optimizations, reducing the need for target-dependent manual +optimizations. An important part of pocl is a set of LLVM passes used to +statically parallelize multiple work-items with the kernel compiler, even in +the presence of work-group barriers. This enables static parallelization of +the fine-grained static concurrency in the work groups in multiple ways. + +TTA-based Co-design Environment (TCE) +------------------------------------- + +`TCE <http://tce.cs.tut.fi/>`_ is a toolset for designing customized +processors based on the Transport Triggered Architecture (TTA). +The toolset provides a complete co-design flow from C/C++ +programs down to synthesizable VHDL/Verilog and parallel program binaries. +Processor customization points include register files, function units, +supported operations, and the interconnection network. + +TCE uses Clang and LLVM for C/C++/OpenCL C language support, target independent +optimizations and also for parts of code generation. It generates new +LLVM-based code generators "on the fly" for the designed TTA processors and +loads them in to the compiler backend as runtime libraries to avoid +per-target recompilation of larger parts of the compiler chain. Additional Information diff --git a/gnu/llvm/docs/conf.py b/gnu/llvm/docs/conf.py index 428a513774e..b71280150ac 100644 --- a/gnu/llvm/docs/conf.py +++ b/gnu/llvm/docs/conf.py @@ -48,9 +48,9 @@ copyright = u'2003-%d, LLVM Project' % date.today().year # built documents. # # The short X.Y version. -version = '4.0' +version = '4' # The full version, including alpha/beta/rc tags. -release = '4.0' +release = '4' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. |