2019-07-18 13:51:05 +02:00
|
|
|
=========================
|
|
|
|
|
LLVM 10.0.0 Release Notes
|
|
|
|
|
=========================
|
2012-12-10 00:14:26 +01:00
|
|
|
|
|
|
|
|
.. contents::
|
|
|
|
|
:local:
|
|
|
|
|
|
2013-01-20 04:29:50 +01:00
|
|
|
.. warning::
|
2019-07-18 13:51:05 +02:00
|
|
|
These are in-progress notes for the upcoming LLVM 10 release.
|
2017-02-10 00:03:34 +01:00
|
|
|
Release notes for previous releases can be found on
|
2018-09-10 10:50:31 +02:00
|
|
|
`the Download Page <https://releases.llvm.org/download.html>`_.
|
2012-12-10 00:14:26 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
This document contains the release notes for the LLVM Compiler Infrastructure,
|
2019-07-18 13:51:05 +02:00
|
|
|
release 10.0.0. Here we describe the status of LLVM, including major improvements
|
2012-12-10 00:14:26 +01: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 10:50:31 +02:00
|
|
|
from the `LLVM releases web site <https://llvm.org/releases/>`_.
|
2012-12-10 00:14:26 +01:00
|
|
|
|
|
|
|
|
For more information about LLVM, including information about the latest
|
2018-09-10 10:50:31 +02:00
|
|
|
release, please check out the `main LLVM web site <https://llvm.org/>`_. If you
|
2012-12-10 00:14:26 +01:00
|
|
|
have questions or comments, the `LLVM Developer's Mailing List
|
2018-09-10 10:50:31 +02:00
|
|
|
<https://lists.llvm.org/mailman/listinfo/llvm-dev>`_ is a good place to send
|
2012-12-10 00:14:26 +01: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 10:50:31 +02:00
|
|
|
page <https://llvm.org/releases/>`_.
|
2012-12-10 00:14:26 +01:00
|
|
|
|
2013-01-20 04:29:50 +01: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 00:14:26 +01:00
|
|
|
|
2019-09-09 19:54:44 +02:00
|
|
|
* The ISD::FP_ROUND_INREG opcode and related code was removed from SelectionDAG.
|
2019-10-16 23:52:09 +02: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-09-09 19:54:44 +02:00
|
|
|
|
2013-01-20 04:29:50 +01: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 00:14:26 +01:00
|
|
|
|
2013-01-20 04:29:50 +01:00
|
|
|
Special New Feature
|
|
|
|
|
-------------------
|
2012-12-10 00:14:26 +01:00
|
|
|
|
2013-01-20 04:29:50 +01:00
|
|
|
Makes programs 10x faster by doing Special New Thing.
|
2012-12-10 00:14:26 +01: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 11:25:02 +02: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.
|
|
|
|
|
|
[LoopIdiomRecognize] Recommit: BCmp loop idiom recognition
Summary:
This is a recommit, this originally landed in rL370454 but was
subsequently reverted in rL370788 due to
https://bugs.llvm.org/show_bug.cgi?id=43206
The reduced testcase was added to bcmp-negative-tests.ll
as @pr43206_different_loops - we must ensure that the SCEV's
we got are both for the same loop we are currently investigating.
Original commit message:
@mclow.lists brought up this issue up in IRC.
It is a reasonably common problem to compare some two values for equality.
Those may be just some integers, strings or arrays of integers.
In C, there is `memcmp()`, `bcmp()` functions.
In C++, there exists `std::equal()` algorithm.
One can also write that function manually.
libstdc++'s `std::equal()` is specialized to directly call `memcmp()` for
various types, but not `std::byte` from C++2a. https://godbolt.org/z/mx2ejJ
libc++ does not do anything like that, it simply relies on simple C++'s
`operator==()`. https://godbolt.org/z/er0Zwf (GOOD!)
So likely, there exists a certain performance opportunities.
Let's compare performance of naive `std::equal()` (no `memcmp()`) with one that
is using `memcmp()` (in this case, compiled with modified compiler). {F8768213}
```
#include <algorithm>
#include <cmath>
#include <cstdint>
#include <iterator>
#include <limits>
#include <random>
#include <type_traits>
#include <utility>
#include <vector>
#include "benchmark/benchmark.h"
template <class T>
bool equal(T* a, T* a_end, T* b) noexcept {
for (; a != a_end; ++a, ++b) {
if (*a != *b) return false;
}
return true;
}
template <typename T>
std::vector<T> getVectorOfRandomNumbers(size_t count) {
std::random_device rd;
std::mt19937 gen(rd());
std::uniform_int_distribution<T> dis(std::numeric_limits<T>::min(),
std::numeric_limits<T>::max());
std::vector<T> v;
v.reserve(count);
std::generate_n(std::back_inserter(v), count,
[&dis, &gen]() { return dis(gen); });
assert(v.size() == count);
return v;
}
struct Identical {
template <typename T>
static std::pair<std::vector<T>, std::vector<T>> Gen(size_t count) {
auto Tmp = getVectorOfRandomNumbers<T>(count);
return std::make_pair(Tmp, std::move(Tmp));
}
};
struct InequalHalfway {
template <typename T>
static std::pair<std::vector<T>, std::vector<T>> Gen(size_t count) {
auto V0 = getVectorOfRandomNumbers<T>(count);
auto V1 = V0;
V1[V1.size() / size_t(2)]++; // just change the value.
return std::make_pair(std::move(V0), std::move(V1));
}
};
template <class T, class Gen>
void BM_bcmp(benchmark::State& state) {
const size_t Length = state.range(0);
const std::pair<std::vector<T>, std::vector<T>> Data =
Gen::template Gen<T>(Length);
const std::vector<T>& a = Data.first;
const std::vector<T>& b = Data.second;
assert(a.size() == Length && b.size() == a.size());
benchmark::ClobberMemory();
benchmark::DoNotOptimize(a);
benchmark::DoNotOptimize(a.data());
benchmark::DoNotOptimize(b);
benchmark::DoNotOptimize(b.data());
for (auto _ : state) {
const bool is_equal = equal(a.data(), a.data() + a.size(), b.data());
benchmark::DoNotOptimize(is_equal);
}
state.SetComplexityN(Length);
state.counters["eltcnt"] =
benchmark::Counter(Length, benchmark::Counter::kIsIterationInvariant);
state.counters["eltcnt/sec"] =
benchmark::Counter(Length, benchmark::Counter::kIsIterationInvariantRate);
const size_t BytesRead = 2 * sizeof(T) * Length;
state.counters["bytes_read/iteration"] =
benchmark::Counter(BytesRead, benchmark::Counter::kDefaults,
benchmark::Counter::OneK::kIs1024);
state.counters["bytes_read/sec"] = benchmark::Counter(
BytesRead, benchmark::Counter::kIsIterationInvariantRate,
benchmark::Counter::OneK::kIs1024);
}
template <typename T>
static void CustomArguments(benchmark::internal::Benchmark* b) {
const size_t L2SizeBytes = []() {
for (const benchmark::CPUInfo::CacheInfo& I :
benchmark::CPUInfo::Get().caches) {
if (I.level == 2) return I.size;
}
return 0;
}();
// What is the largest range we can check to always fit within given L2 cache?
const size_t MaxLen = L2SizeBytes / /*total bufs*/ 2 /
/*maximal elt size*/ sizeof(T) / /*safety margin*/ 2;
b->RangeMultiplier(2)->Range(1, MaxLen)->Complexity(benchmark::oN);
}
BENCHMARK_TEMPLATE(BM_bcmp, uint8_t, Identical)
->Apply(CustomArguments<uint8_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint16_t, Identical)
->Apply(CustomArguments<uint16_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint32_t, Identical)
->Apply(CustomArguments<uint32_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint64_t, Identical)
->Apply(CustomArguments<uint64_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint8_t, InequalHalfway)
->Apply(CustomArguments<uint8_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint16_t, InequalHalfway)
->Apply(CustomArguments<uint16_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint32_t, InequalHalfway)
->Apply(CustomArguments<uint32_t>);
BENCHMARK_TEMPLATE(BM_bcmp, uint64_t, InequalHalfway)
->Apply(CustomArguments<uint64_t>);
```
{F8768210}
```
$ ~/src/googlebenchmark/tools/compare.py --no-utest benchmarks build-{old,new}/test/llvm-bcmp-bench
RUNNING: build-old/test/llvm-bcmp-bench --benchmark_out=/tmp/tmpb6PEUx
2019-04-25 21:17:11
Running build-old/test/llvm-bcmp-bench
Run on (8 X 4000 MHz CPU s)
CPU Caches:
L1 Data 16K (x8)
L1 Instruction 64K (x4)
L2 Unified 2048K (x4)
L3 Unified 8192K (x1)
Load Average: 0.65, 3.90, 4.14
---------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
---------------------------------------------------------------------------------------------------
<...>
BM_bcmp<uint8_t, Identical>/512000 432131 ns 432101 ns 1613 bytes_read/iteration=1000k bytes_read/sec=2.20706G/s eltcnt=825.856M eltcnt/sec=1.18491G/s
BM_bcmp<uint8_t, Identical>_BigO 0.86 N 0.86 N
BM_bcmp<uint8_t, Identical>_RMS 8 % 8 %
<...>
BM_bcmp<uint16_t, Identical>/256000 161408 ns 161409 ns 4027 bytes_read/iteration=1000k bytes_read/sec=5.90843G/s eltcnt=1030.91M eltcnt/sec=1.58603G/s
BM_bcmp<uint16_t, Identical>_BigO 0.67 N 0.67 N
BM_bcmp<uint16_t, Identical>_RMS 25 % 25 %
<...>
BM_bcmp<uint32_t, Identical>/128000 81497 ns 81488 ns 8415 bytes_read/iteration=1000k bytes_read/sec=11.7032G/s eltcnt=1077.12M eltcnt/sec=1.57078G/s
BM_bcmp<uint32_t, Identical>_BigO 0.71 N 0.71 N
BM_bcmp<uint32_t, Identical>_RMS 42 % 42 %
<...>
BM_bcmp<uint64_t, Identical>/64000 50138 ns 50138 ns 10909 bytes_read/iteration=1000k bytes_read/sec=19.0209G/s eltcnt=698.176M eltcnt/sec=1.27647G/s
BM_bcmp<uint64_t, Identical>_BigO 0.84 N 0.84 N
BM_bcmp<uint64_t, Identical>_RMS 27 % 27 %
<...>
BM_bcmp<uint8_t, InequalHalfway>/512000 192405 ns 192392 ns 3638 bytes_read/iteration=1000k bytes_read/sec=4.95694G/s eltcnt=1.86266G eltcnt/sec=2.66124G/s
BM_bcmp<uint8_t, InequalHalfway>_BigO 0.38 N 0.38 N
BM_bcmp<uint8_t, InequalHalfway>_RMS 3 % 3 %
<...>
BM_bcmp<uint16_t, InequalHalfway>/256000 127858 ns 127860 ns 5477 bytes_read/iteration=1000k bytes_read/sec=7.45873G/s eltcnt=1.40211G eltcnt/sec=2.00219G/s
BM_bcmp<uint16_t, InequalHalfway>_BigO 0.50 N 0.50 N
BM_bcmp<uint16_t, InequalHalfway>_RMS 0 % 0 %
<...>
BM_bcmp<uint32_t, InequalHalfway>/128000 49140 ns 49140 ns 14281 bytes_read/iteration=1000k bytes_read/sec=19.4072G/s eltcnt=1.82797G eltcnt/sec=2.60478G/s
BM_bcmp<uint32_t, InequalHalfway>_BigO 0.40 N 0.40 N
BM_bcmp<uint32_t, InequalHalfway>_RMS 18 % 18 %
<...>
BM_bcmp<uint64_t, InequalHalfway>/64000 32101 ns 32099 ns 21786 bytes_read/iteration=1000k bytes_read/sec=29.7101G/s eltcnt=1.3943G eltcnt/sec=1.99381G/s
BM_bcmp<uint64_t, InequalHalfway>_BigO 0.50 N 0.50 N
BM_bcmp<uint64_t, InequalHalfway>_RMS 1 % 1 %
RUNNING: build-new/test/llvm-bcmp-bench --benchmark_out=/tmp/tmpQ46PP0
2019-04-25 21:19:29
Running build-new/test/llvm-bcmp-bench
Run on (8 X 4000 MHz CPU s)
CPU Caches:
L1 Data 16K (x8)
L1 Instruction 64K (x4)
L2 Unified 2048K (x4)
L3 Unified 8192K (x1)
Load Average: 1.01, 2.85, 3.71
---------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
---------------------------------------------------------------------------------------------------
<...>
BM_bcmp<uint8_t, Identical>/512000 18593 ns 18590 ns 37565 bytes_read/iteration=1000k bytes_read/sec=51.2991G/s eltcnt=19.2333G eltcnt/sec=27.541G/s
BM_bcmp<uint8_t, Identical>_BigO 0.04 N 0.04 N
BM_bcmp<uint8_t, Identical>_RMS 37 % 37 %
<...>
BM_bcmp<uint16_t, Identical>/256000 18950 ns 18948 ns 37223 bytes_read/iteration=1000k bytes_read/sec=50.3324G/s eltcnt=9.52909G eltcnt/sec=13.511G/s
BM_bcmp<uint16_t, Identical>_BigO 0.08 N 0.08 N
BM_bcmp<uint16_t, Identical>_RMS 34 % 34 %
<...>
BM_bcmp<uint32_t, Identical>/128000 18627 ns 18627 ns 37895 bytes_read/iteration=1000k bytes_read/sec=51.198G/s eltcnt=4.85056G eltcnt/sec=6.87168G/s
BM_bcmp<uint32_t, Identical>_BigO 0.16 N 0.16 N
BM_bcmp<uint32_t, Identical>_RMS 35 % 35 %
<...>
BM_bcmp<uint64_t, Identical>/64000 18855 ns 18855 ns 37458 bytes_read/iteration=1000k bytes_read/sec=50.5791G/s eltcnt=2.39731G eltcnt/sec=3.3943G/s
BM_bcmp<uint64_t, Identical>_BigO 0.32 N 0.32 N
BM_bcmp<uint64_t, Identical>_RMS 33 % 33 %
<...>
BM_bcmp<uint8_t, InequalHalfway>/512000 9570 ns 9569 ns 73500 bytes_read/iteration=1000k bytes_read/sec=99.6601G/s eltcnt=37.632G eltcnt/sec=53.5046G/s
BM_bcmp<uint8_t, InequalHalfway>_BigO 0.02 N 0.02 N
BM_bcmp<uint8_t, InequalHalfway>_RMS 29 % 29 %
<...>
BM_bcmp<uint16_t, InequalHalfway>/256000 9547 ns 9547 ns 74343 bytes_read/iteration=1000k bytes_read/sec=99.8971G/s eltcnt=19.0318G eltcnt/sec=26.8159G/s
BM_bcmp<uint16_t, InequalHalfway>_BigO 0.04 N 0.04 N
BM_bcmp<uint16_t, InequalHalfway>_RMS 29 % 29 %
<...>
BM_bcmp<uint32_t, InequalHalfway>/128000 9396 ns 9394 ns 73521 bytes_read/iteration=1000k bytes_read/sec=101.518G/s eltcnt=9.41069G eltcnt/sec=13.6255G/s
BM_bcmp<uint32_t, InequalHalfway>_BigO 0.08 N 0.08 N
BM_bcmp<uint32_t, InequalHalfway>_RMS 30 % 30 %
<...>
BM_bcmp<uint64_t, InequalHalfway>/64000 9499 ns 9498 ns 73802 bytes_read/iteration=1000k bytes_read/sec=100.405G/s eltcnt=4.72333G eltcnt/sec=6.73808G/s
BM_bcmp<uint64_t, InequalHalfway>_BigO 0.16 N 0.16 N
BM_bcmp<uint64_t, InequalHalfway>_RMS 28 % 28 %
Comparing build-old/test/llvm-bcmp-bench to build-new/test/llvm-bcmp-bench
Benchmark Time CPU Time Old Time New CPU Old CPU New
---------------------------------------------------------------------------------------------------------------------------------------
<...>
BM_bcmp<uint8_t, Identical>/512000 -0.9570 -0.9570 432131 18593 432101 18590
<...>
BM_bcmp<uint16_t, Identical>/256000 -0.8826 -0.8826 161408 18950 161409 18948
<...>
BM_bcmp<uint32_t, Identical>/128000 -0.7714 -0.7714 81497 18627 81488 18627
<...>
BM_bcmp<uint64_t, Identical>/64000 -0.6239 -0.6239 50138 18855 50138 18855
<...>
BM_bcmp<uint8_t, InequalHalfway>/512000 -0.9503 -0.9503 192405 9570 192392 9569
<...>
BM_bcmp<uint16_t, InequalHalfway>/256000 -0.9253 -0.9253 127858 9547 127860 9547
<...>
BM_bcmp<uint32_t, InequalHalfway>/128000 -0.8088 -0.8088 49140 9396 49140 9394
<...>
BM_bcmp<uint64_t, InequalHalfway>/64000 -0.7041 -0.7041 32101 9499 32099 9498
```
What can we tell from the benchmark?
* Performance of naive equality check somewhat improves with element size,
maxing out at eltcnt/sec=1.58603G/s for uint16_t, or bytes_read/sec=19.0209G/s
for uint64_t. I think, that instability implies performance problems.
* Performance of `memcmp()`-aware benchmark always maxes out at around
bytes_read/sec=51.2991G/s for every type. That is 2.6x the throughput of the
naive variant!
* eltcnt/sec metric for the `memcmp()`-aware benchmark maxes out at
eltcnt/sec=27.541G/s for uint8_t (was: eltcnt/sec=1.18491G/s, so 24x) and
linearly decreases with element size.
For uint64_t, it's ~4x+ the elements/second.
* The call obvious is more pricey than the loop, with small element count.
As it can be seen from the full output {F8768210}, the `memcmp()` is almost
universally worse, independent of the element size (and thus buffer size) when
element count is less than 8.
So all in all, bcmp idiom does indeed pose untapped performance headroom.
This diff does implement said idiom recognition. I think a reasonable test
coverage is present, but do tell if there is anything obvious missing.
Now, quality. This does succeed to build and pass the test-suite, at least
without any non-bundled elements. {F8768216} {F8768217}
This transform fires 91 times:
```
$ /build/test-suite/utils/compare.py -m loop-idiom.NumBCmp result-new.json
Tests: 1149
Metric: loop-idiom.NumBCmp
Program result-new
MultiSourc...Benchmarks/7zip/7zip-benchmark 79.00
MultiSource/Applications/d/make_dparser 3.00
SingleSource/UnitTests/vla 2.00
MultiSource/Applications/Burg/burg 1.00
MultiSourc.../Applications/JM/lencod/lencod 1.00
MultiSource/Applications/lemon/lemon 1.00
MultiSource/Benchmarks/Bullet/bullet 1.00
MultiSourc...e/Benchmarks/MallocBench/gs/gs 1.00
MultiSourc...gs-C/TimberWolfMC/timberwolfmc 1.00
MultiSourc...Prolangs-C/simulator/simulator 1.00
```
The size changes are:
I'm not sure what's going on with SingleSource/UnitTests/vla.test yet, did not look.
```
$ /build/test-suite/utils/compare.py -m size..text result-{old,new}.json --filter-hash
Tests: 1149
Same hash: 907 (filtered out)
Remaining: 242
Metric: size..text
Program result-old result-new diff
test-suite...ingleSource/UnitTests/vla.test 753.00 833.00 10.6%
test-suite...marks/7zip/7zip-benchmark.test 1001697.00 966657.00 -3.5%
test-suite...ngs-C/simulator/simulator.test 32369.00 32321.00 -0.1%
test-suite...plications/d/make_dparser.test 89585.00 89505.00 -0.1%
test-suite...ce/Applications/Burg/burg.test 40817.00 40785.00 -0.1%
test-suite.../Applications/lemon/lemon.test 47281.00 47249.00 -0.1%
test-suite...TimberWolfMC/timberwolfmc.test 250065.00 250113.00 0.0%
test-suite...chmarks/MallocBench/gs/gs.test 149889.00 149873.00 -0.0%
test-suite...ications/JM/lencod/lencod.test 769585.00 769569.00 -0.0%
test-suite.../Benchmarks/Bullet/bullet.test 770049.00 770049.00 0.0%
test-suite...HMARK_ANISTROPIC_DIFFUSION/128 NaN NaN nan%
test-suite...HMARK_ANISTROPIC_DIFFUSION/256 NaN NaN nan%
test-suite...CHMARK_ANISTROPIC_DIFFUSION/64 NaN NaN nan%
test-suite...CHMARK_ANISTROPIC_DIFFUSION/32 NaN NaN nan%
test-suite...ENCHMARK_BILATERAL_FILTER/64/4 NaN NaN nan%
Geomean difference nan%
result-old result-new diff
count 1.000000e+01 10.00000 10.000000
mean 3.152090e+05 311695.40000 0.006749
std 3.790398e+05 372091.42232 0.036605
min 7.530000e+02 833.00000 -0.034981
25% 4.243300e+04 42401.00000 -0.000866
50% 1.197370e+05 119689.00000 -0.000392
75% 6.397050e+05 639705.00000 -0.000005
max 1.001697e+06 966657.00000 0.106242
```
I don't have timings though.
And now to the code. The basic idea is to completely replace the whole loop.
If we can't fully kill it, don't transform.
I have left one or two comments in the code, so hopefully it can be understood.
Also, there is a few TODO's that i have left for follow-ups:
* widening of `memcmp()`/`bcmp()`
* step smaller than the comparison size
* Metadata propagation
* more than two blocks as long as there is still a single backedge?
* ???
Reviewers: reames, fhahn, mkazantsev, chandlerc, craig.topper, courbet
Reviewed By: courbet
Subscribers: miyuki, hiraditya, xbolva00, nikic, jfb, gchatelet, courbet, llvm-commits, mclow.lists
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61144
llvm-svn: 374662
2019-10-12 17:35:32 +02:00
|
|
|
* The Loop Idiom Recognition (``-loop-idiom``) pass has learned to recognize
|
|
|
|
|
``bcmp`` pattern, and convert it into a call to ``bcmp`` (or ``memcmp``)
|
|
|
|
|
function.
|
[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 11:25:02 +02:00
|
|
|
|
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 14:22:19 +01: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.
|
|
|
|
|
|
2016-03-29 08:55:56 +02:00
|
|
|
Changes to the LLVM IR
|
|
|
|
|
----------------------
|
|
|
|
|
|
2019-08-03 16:28:34 +02: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 12:10:48 +02:00
|
|
|
Changes to building LLVM
|
|
|
|
|
------------------------
|
|
|
|
|
|
2014-03-18 11:16:15 +01:00
|
|
|
Changes to the ARM Backend
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2014-08-22 23:57:38 +02:00
|
|
|
During this release ...
|
|
|
|
|
|
2014-03-18 11:16:15 +01:00
|
|
|
|
2014-07-23 14:59:26 +02:00
|
|
|
Changes to the MIPS Target
|
|
|
|
|
--------------------------
|
|
|
|
|
|
2015-01-14 19:07:30 +01:00
|
|
|
During this release ...
|
2015-01-11 11:34:52 +01:00
|
|
|
|
2014-07-23 14:59:26 +02:00
|
|
|
|
2014-07-31 16:38:17 +02:00
|
|
|
Changes to the PowerPC Target
|
2014-07-31 17:20:30 +02:00
|
|
|
-----------------------------
|
2014-07-31 16:38:17 +02:00
|
|
|
|
2016-07-18 20:02:23 +02:00
|
|
|
During this release ...
|
2014-07-31 16:38:17 +02:00
|
|
|
|
2015-12-21 03:37:23 +01:00
|
|
|
Changes to the X86 Target
|
2016-03-29 08:55:56 +02:00
|
|
|
-------------------------
|
2015-12-21 03:37:23 +01:00
|
|
|
|
2019-01-16 11:57:02 +01:00
|
|
|
During this release ...
|
2015-12-21 03:37:23 +01:00
|
|
|
|
2019-08-28 19:18:56 +02: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-30 19:35:08 +02: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 01:54:36 +02: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-08-28 19:18:56 +02:00
|
|
|
|
2016-01-26 05:29:15 +01:00
|
|
|
Changes to the AMDGPU Target
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2016-11-17 23:26:09 +01:00
|
|
|
Changes to the AVR Target
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2017-01-12 22:50:22 +01:00
|
|
|
During this release ...
|
2016-11-17 23:26:09 +01:00
|
|
|
|
2019-08-29 20:09:02 +02: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.
|
|
|
|
|
|
2019-01-14 19:20:30 +01:00
|
|
|
Changes to the WebAssembly Target
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
2019-01-16 11:57:02 +01:00
|
|
|
During this release ...
|
2019-01-15 18:54:42 +01:00
|
|
|
|
2019-01-14 19:20:30 +01:00
|
|
|
|
2015-01-13 10:48:02 +01:00
|
|
|
Changes to the OCaml bindings
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
|
|
|
|
|
2016-02-17 20:35:47 +01:00
|
|
|
|
2017-06-30 03:17:45 +02:00
|
|
|
Changes to the C API
|
|
|
|
|
--------------------
|
|
|
|
|
|
2017-06-30 09:09:08 +02: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 15:21:33 +02:00
|
|
|
Changes to the DAG infrastructure
|
|
|
|
|
---------------------------------
|
2018-06-04 20:36:22 +02:00
|
|
|
|
2019-07-05 19:58:30 +02:00
|
|
|
Changes to LLDB
|
|
|
|
|
===============
|
|
|
|
|
|
2019-07-18 13:51:05 +02:00
|
|
|
External Open Source Projects Using LLVM 10
|
|
|
|
|
===========================================
|
2015-01-13 10:48:02 +01:00
|
|
|
|
2016-07-18 20:02:23 +02:00
|
|
|
* A project...
|
2013-11-14 06:57:40 +01:00
|
|
|
|
|
|
|
|
|
2012-12-10 00:14:26 +01:00
|
|
|
Additional Information
|
|
|
|
|
======================
|
|
|
|
|
|
|
|
|
|
A wide variety of additional information is available on the `LLVM web page
|
2018-09-10 10:50:31 +02: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 00:14:26 +01: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 10:50:31 +02:00
|
|
|
us via the `mailing lists <https://llvm.org/docs/#mailing-lists>`_.
|
