OSDN Git Service

Release note for DWARF v5 support
[android-x86/external-llvm.git] / docs / ReleaseNotes.rst
index e241294..58fb882 100644 (file)
@@ -1,21 +1,21 @@
-======================
-LLVM 3.5 Release Notes
-======================
+========================
+LLVM 7.0.0 Release Notes
+========================
 
 .. contents::
     :local:
 
 .. warning::
-   These are in-progress notes for the upcoming LLVM 3.5 release.  You may
-   prefer the `LLVM 3.4 Release Notes <http://llvm.org/releases/3.4/docs
-   /ReleaseNotes.html>`_.
+   These are in-progress notes for the upcoming LLVM 7 release.
+   Release notes for previous releases can be found on
+   `the Download Page <http://releases.llvm.org/download.html>`_.
 
 
 Introduction
 ============
 
 This document contains the release notes for the LLVM Compiler Infrastructure,
-release 3.5.  Here we describe the status of LLVM, including major improvements
+release 7.0.0.  Here we describe the status of LLVM, including major improvements
 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
 from the `LLVM releases web site <http://llvm.org/releases/>`_.
@@ -23,7 +23,7 @@ from the `LLVM releases web site <http://llvm.org/releases/>`_.
 For more information about LLVM, including information about the latest
 release, please check out the `main LLVM web site <http://llvm.org/>`_.  If you
 have questions or comments, the `LLVM Developer's Mailing List
-<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ is a good place to send
+<http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ is a good place to send
 them.
 
 Note that if you are reading this file from a Subversion checkout or the main
@@ -33,46 +33,89 @@ page <http://llvm.org/releases/>`_.
 
 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.
 
-* All backends have been changed to use the MC asm printer and support for the
-  non MC one has been removed.
+* Libraries have been renamed from 7.0 to 7. This change also impacts
+  downstream libraries like lldb.
 
-* Clang can now successfully self-host itself on Linux/Sparc64 and on
-  FreeBSD/Sparc64.
+* The LoopInstSimplify pass (-loop-instsimplify) has been removed.
 
-* LLVM now assumes the assembler supports ``.loc`` for generating debug line
-  numbers. The old support for printing the debug line info directly was only
-  used by ``llc`` and has been removed.
+* Symbols starting with ``?`` are no longer mangled by LLVM when using the
+  Windows ``x`` or ``w`` IR mangling schemes.
 
-* All inline assembly is parsed by the integrated assembler when it is enabled.
-  Previously this was only the case for object-file output. It is now the case
-  for assembly output as well. The integrated assembler can be disabled with
-  the ``-no-integrated-as`` option.
+* A new tool named :doc:`llvm-exegesis <CommandGuide/llvm-exegesis>` has been
+  added. :program:`llvm-exegesis` automatically measures instruction scheduling
+  properties (latency/uops) and provides a principled way to edit scheduling
+  models.
 
-* llvm-ar now handles IR files like regular object files. In particular, a
-  regular symbol table is created for symbols defined in IR files, including
-  those in file scope inline assembly.
+* A new tool named :doc:`llvm-mca <CommandGuide/llvm-mca>` has been added.
+  :program:`llvm-mca` is a  static performance analysis tool that uses
+  information available in LLVM to statically predict the performance of
+  machine code for a specific CPU.
 
-* LLVM now always uses cfi directives for producing most stack
-  unwinding information.
+* The optimization flag to merge constants (-fmerge-all-constants) is no longer
+  applied by default.
 
-* The prefix for loop vectorizer hint metadata has been changed from
-  ``llvm.vectorizer`` to ``llvm.loop.vectorize``.  In addition,
-  ``llvm.vectorizer.unroll`` metadata has been renamed
-  ``llvm.loop.interleave.count``.
+* Optimization of floating-point casts is improved. This may cause surprising
+  results for code that is relying on the undefined behavior of overflowing 
+  casts. The optimization can be disabled by specifying a function attribute:
+  "strict-float-cast-overflow"="false". This attribute may be created by the
+  clang option ``-fno-strict-float-cast-overflow``.
+  Code sanitizers can be used to detect affected patterns. The option for
+  detecting this problem alone is "-fsanitize=float-cast-overflow":
 
-* Some backends previously implemented Atomic NAND(x,y) as ``x & ~y``. Now 
-  all backends implement it as ``~(x & y)``, matching the semantics of GCC 4.4
-  and later.
+.. code-block:: c
 
-.. 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.
+    int main() {
+      float x = 4294967296.0f;
+      x = (float)((int)x);
+      printf("junk in the ftrunc: %f\n", x);
+      return 0;
+    }
+
+.. code-block:: bash
+
+    clang -O1 ftrunc.c -fsanitize=float-cast-overflow ; ./a.out 
+    ftrunc.c:5:15: runtime error: 4.29497e+09 is outside the range of representable values of type 'int'
+    junk in the ftrunc: 0.000000
+
+* ``LLVM_ON_WIN32`` is no longer set by ``llvm/Config/config.h`` and
+  ``llvm/Config/llvm-config.h``.  If you used this macro, use the compiler-set
+  ``_WIN32`` instead which is set exactly when ``LLVM_ON_WIN32`` used to be set.
+
+* The ``DEBUG`` macro has been renamed to ``LLVM_DEBUG``, the interface remains
+  the same.  If you used this macro you need to migrate to the new one.
+  You should also clang-format your code to make it easier to integrate future
+  changes locally.  This can be done with the following bash commands:
 
-* ... next change ...
+.. code-block:: bash
+
+    git grep -l 'DEBUG' | xargs perl -pi -e 's/\bDEBUG\s?\(/LLVM_DEBUG(/g'
+    git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
+
+* Early support for UBsan, X-Ray instrumentation and libFuzzer (x86 and x86_64) for OpenBSD. Support for MSan
+  (x86_64), X-Ray instrumentation and libFuzzer (x86 and x86_64) for FreeBSD.
+
+* ``SmallVector<T, 0>`` shrank from ``sizeof(void*) * 4 + sizeof(T)`` to
+  ``sizeof(void*) + sizeof(unsigned) * 2``, smaller than ``std::vector<T>`` on
+  64-bit platforms.  The maximum capacity is now restricted to ``UINT32_MAX``.
+  Since SmallVector doesn't have the exception-safety pessimizations some
+  implementations saddle std::vector with and is better at using ``realloc``,
+  it's now a better choice even on the heap (although when TinyPtrVector works,
+  it's even smaller).
+
+* Preliminary/experimental support for DWARF v5 debugging information,
+  including the new .debug_names accelerator table. DWARF emitted at ``-O0``
+  should be fully DWARF v5 compliant. Type units and split DWARF are known
+  not to be compliant, and higher optimization levels will still emit some
+  information in v4 format.
+
+* Note..
 
 .. NOTE
    If you would like to document a larger change, then you can add a
@@ -84,140 +127,75 @@ Non-comprehensive list of changes in this release
 
    Makes programs 10x faster by doing Special New Thing.
 
-Changes to the ARM Backend
---------------------------
-
-Since release 3.3, a lot of new features have been included in the ARM
-back-end but weren't production ready (ie. well tested) on release 3.4.
-Just after the 3.4 release, we started heavily testing two major parts
-of the back-end: the integrated assembler (IAS) and the ARM exception
-handling (EHABI), and now they are enabled by default on LLVM/Clang.
-
-The IAS received a lot of GNU extensions and directives, as well as some
-specific pre-UAL instructions. Not all remaining directives will be
-implemented, as we made judgement calls on the need versus the complexity,
-and have chosen simplicity and future compatibility where hard decisions
-had to be made. The major difference is, as stated above, the IAS validates
-all inline ASM, not just for object emission, and that cause trouble with
-some uses of inline ASM as pre-processor magic.
-
-So, while the IAS is good enough to compile large projects (including most
-of the Linux kernel), there are a few things that we can't (and probably
-won't) do. For those cases, please use ``-fno-integrated-as`` in Clang.
-
-Exception handling is another big change. After extensive testing and
-changes to cooperate with Dwarf unwinding, EHABI is enabled by default.
-The options ``-arm-enable-ehabi`` and ``-arm-enable-ehabi-descriptors``,
-which were used to enable EHABI in the previous releases, are removed now.
-
-This means all ARM code will emit EH unwind tables, or CFI unwinding (for
-debug/profiling), or both. To avoid run-time inconsistencies, C code will
-also emit EH tables (in case they interoperate with C++ code), as is the
-case for other architectures (ex. x86_64).
-
-Changes to the MIPS Target
---------------------------
+Changes to the LLVM IR
+----------------------
 
-There has been a large amount of improvements to the MIPS target which can be
-broken down into subtarget, ABI, and Integrated Assembler changes.
+* The signatures for the builtins @llvm.memcpy, @llvm.memmove, and @llvm.memset
+  have changed. Alignment is no longer an argument, and are instead conveyed as
+  parameter attributes.
 
-Subtargets
-^^^^^^^^^^
+* invariant.group.barrier has been renamed to launder.invariant.group.
 
-Added support for Release 6 of the MIPS32 and MIPS64 architecture (MIPS32r6
-and MIPS64r6). Release 6 makes a number of significant changes to the MIPS32
-and MIPS64 architectures. For example, FPU registers are always 64-bits wide,
-FPU NaN values conform to IEEE 754 (2008), and the unaligned memory instructions
-(such as lwl and lwr) have been replaced with a requirement for ordinary memory
-operations to support unaligned operations. Full details of MIPS32 and MIPS64
-Release 6 can be found on the `MIPS64 Architecture page at Imagination
-Technologies <http://www.imgtec.com/mips/architectures/mips64.asp>`_.
+* invariant.group metadata can now refer only empty metadata nodes.
 
-This release also adds experimental support for MIPS-IV, cnMIPS, and Cavium
-Octeon CPU's.
+Changes to the ARM Backend
+--------------------------
 
-Support for the MIPS SIMD Architecture (MSA) has been improved to support MSA
-on MIPS64.
+ During this release ...
 
-Support for IEEE 754 (2008) NaN values has been added.
 
-ABI and ABI extensions
-^^^^^^^^^^^^^^^^^^^^^^
+Changes to the MIPS Target
+--------------------------
 
-There has also been considerable ABI work since the 3.4 release. This release
-adds support for the N32 ABI, the O32-FPXX ABI Extension, the O32-FP64 ABI
-Extension, and the O32-FP64A ABI Extension.
+ During this release ...
 
-The N32 ABI is an existing ABI that has now been implemented in LLVM. It is a
-64-bit ABI that is similar to N64 but retains 32-bit pointers. N64 remains the
-default 64-bit ABI in LLVM. This differs from GCC where N32 is the default
-64-bit ABI.
 
-The O32-FPXX ABI Extension is 100% compatible with the O32-ABI and the O32-FP64
-ABI Extension and may be linked with either but may not be linked with both of
-these simultaneously. It extends the O32 ABI to allow the same code to execute
-without modification on processors with 32-bit FPU registers as well as 64-bit
-FPU registers. The O32-FPXX ABI Extension is enabled by default for the O32 ABI
-on mips*-img-linux-gnu and mips*-mti-linux-gnu triples and is selected with
--mfpxx. It is expected that future releases of LLVM will enable the FPXX
-Extension for O32 on all triples.
+Changes to the PowerPC Target
+-----------------------------
 
-The O32-FP64 ABI Extension is an extension to the O32 ABI to fully exploit FPU's
-with 64-bit registers and is enabled with -mfp64. This replaces an undocumented
-and unsupported O32 extension which was previously enabled with -mfp64. It is
-100% compatible with the O32-FPXX ABI Extension.
+ During this release ...
 
-The O32-FP64A ABI Extension is a restricted form of the O32-FP64 ABI Extension
-which allows interlinking with unmodified binaries that use the base O32 ABI.
+Changes to the X86 Target
+-------------------------
 
-Integrated Assembler
-^^^^^^^^^^^^^^^^^^^^
+ During this release ...
 
-The MIPS Integrated Assembler has undergone a substantial overhaul including a
-rewrite of the assembly parser. It's not ready for general use in this release
-but adventurous users may wish to enable it using ``-fintegrated-as``.
+Changes to the AMDGPU Target
+-----------------------------
 
-In this release, the integrated assembler supports the majority of MIPS-I,
-MIPS-II, MIPS-III, MIPS-IV, MIPS-V, MIPS32, MIPS32r2, MIPS32r6, MIPS64,
-MIPS64r2, and MIPS64r6 as well as some of the Application Specific Extensions
-such as MSA. It also supports several of the MIPS specific assembler directives
-such as ``.set``, ``.module``, ``.cpload``, etc.
+ During this release ...
 
-Changes to the PowerPC Target
-=============================
+Changes to the AVR Target
+-----------------------------
 
-The PowerPC 64-bit Little Endian subtarget (powerpc64le-unknown-linux-gnu) is
-now fully supported.  This includes support for the Altivec instruction set.
+ During this release ...
 
-The Power Architecture 64-Bit ELFv2 ABI Specification is now supported, and
-is the default ABI for Little Endian.  The ELFv1 ABI remains the default ABI
-for Big Endian.  Currently, it is not possible to override these defaults.
-That capability will be available (albeit not recommended) in a future release.
+Changes to the OCaml bindings
+-----------------------------
 
-Links to the ELFv2 ABI specification and to the Power ISA Version 2.07
-specification may be found `here <https://www-03.ibm.com/technologyconnect/tgcm/TGCMServlet.wss?alias=OpenPOWER&linkid=1n0000>`_ (free registration required).
-Efforts are underway to move this to a location that doesn't require
-registration, but the planned site isn't ready yet.
+* Remove ``add_bb_vectorize``.
 
-Experimental support for the VSX instruction set introduced with ISA 2.06
-is now available using the ``-mvsx`` switch.  Work remains on this, so it
-is not recommended for production use.  VSX is disabled for Little Endian
-regardless of this switch setting.
 
-Load/store cost estimates have been improved.
+Changes to the C API
+--------------------
 
-Constant hoisting has been enabled.
+* Remove ``LLVMAddBBVectorizePass``. The implementation was removed and the C
+  interface was made a deprecated no-op in LLVM 5. Use
+  ``LLVMAddSLPVectorizePass`` instead to get the supported SLP vectorizer.
 
-Global named register support has been enabled.
+Changes to the DAG infrastructure
+---------------------------------
+* ADDC/ADDE/SUBC/SUBE are now deprecated and will default to expand. Backends
+  that wish to continue to use these opcodes should explicitely request so
+  using ``setOperationAction`` in their ``TargetLowering``. New backends
+  should use UADDO/ADDCARRY/USUBO/SUBCARRY instead of the deprecated opcodes.
 
-Position-independent code can now be generated for the 32-bit ELF subtarget.
+* The SETCCE opcode has now been removed in favor of SETCCCARRY.
 
-External Open Source Projects Using LLVM 3.5
-============================================
+External Open Source Projects Using LLVM 7
+==========================================
 
-An exciting aspect of LLVM is that it is used as an enabling technology for
-a lot of other language and tools projects. This section lists some of the
-projects that have already been updated to work with LLVM 3.5.
+* A project...
 
 
 Additional Information
@@ -232,4 +210,3 @@ going into the ``llvm/docs/`` directory in the LLVM tree.
 
 If you have any questions or comments about LLVM, please feel free to contact
 us via the `mailing lists <http://llvm.org/docs/#maillist>`_.
-