RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2024-11-23 19:59:48 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
fa594c6082
llvm/docs/ReleaseNotes.rst
Roman Lebedev 318bd27505 [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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@374293 91177308-0d34-0410-b5e6-96231b3b80d8
2019-10-10 09:25:02 +00:00

169 lines
5.8 KiB
ReStructuredText
Raw Blame History

=========================
LLVM 10.0.0 Release Notes
=========================
.. contents::
:local:
.. warning::
These are in-progress notes for the upcoming LLVM 10 release.
Release notes for previous releases can be found on
`the Download Page <https://releases.llvm.org/download.html>`_.
Introduction
============
This document contains the release notes for the LLVM Compiler Infrastructure,
release 10.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 <https://llvm.org/releases/>`_.
For more information about LLVM, including information about the latest
release, please check out the `main LLVM web site <https://llvm.org/>`_. If you
have questions or comments, the `LLVM Developer's Mailing List
<https://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
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
page <https://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.
* The ISD::FP_ROUND_INREG opcode and related code was removed from SelectionDAG.
* Enabled MemorySSA as a loop dependency.
.. 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.
* 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.
Changes to the LLVM IR
----------------------
* 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.
Changes to building LLVM
------------------------
Changes to the ARM Backend
--------------------------
During this release ...
Changes to the MIPS Target
--------------------------
During this release ...
Changes to the PowerPC Target
-----------------------------
During this release ...
Changes to the X86 Target
-------------------------
During this release ...
* 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.
* 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
* -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.
Changes to the AMDGPU Target
-----------------------------
Changes to the AVR Target
-----------------------------
During this release ...
* 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.
Changes to the WebAssembly Target
---------------------------------
During this release ...
Changes to the OCaml bindings
-----------------------------
Changes to the C API
--------------------
Changes to the DAG infrastructure
---------------------------------
Changes to LLDB
===============
External Open Source Projects Using LLVM 10
===========================================
* A project...
Additional Information
======================
A wide variety of additional information is available on the `LLVM web page
<https://llvm.org/>`_, in particular in the `documentation
<https://llvm.org/docs/>`_ section. The web page also contains versions of the
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
us via the `mailing lists <https://llvm.org/docs/#mailing-lists>`_.
Reference in New Issue View Git Blame Copy Permalink