| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This augments the STLExtras toolset with a zip iterator and range
adapter. Zip comes in two varieties: `zip`, which will zip to the
shortest of the input ranges, and `zip_first`, which limits its
`begin() == end()` checks to just the first krange.
Patch by: Bryant Wong <github.com/bryant>
Differential Revision: https://reviews.llvm.org/D23252
llvm-svn: 284035
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add unit tests for checking a few tricky instruction sizes. Also remove the old
tests for the instruction sizes, which were clunky and brittle.
Since this is the first set of target-specific unit tests, we need to add some
CMake plumbing. In the future, adding unit tests for a given target will be as
simple as creating a directory with the same name as the target under
unittests/Target. The tests are only run if the target is enabled in
LLVM_TARGETS_TO_BUILD.
Differential Revision: https://reviews.llvm.org/D24548
llvm-svn: 283990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basic inlining operation makes the following changes to the call graph:
1) Add edges that were previously transitive edges. This is always trivial and
this patch gives the LCG helper methods to make this more convenient.
2) Remove the inlined edge. We had existing support for this, but it contained
bugs that needed to be fixed. Testing in the same pattern as the inliner
exposes these bugs very nicely.
3) Delete a function when it becomes dead because it is internal and all calls
have been inlined. The LCG had no support at all for this operation, so this
adds that support.
Two unittests have been added that exercise this specific mutation pattern to
the call graph. They were extremely effective in uncovering bugs. Sadly,
a large fraction of the code here is just to implement those unit tests, but
I think they're paying for themselves. =]
This was split out of a patch that actually uses the routines to
implement inlining in the new pass manager in order to isolate (with
unit tests) the logic that was entirely within the LCG.
Many thanks for the careful review from folks! There will be a few minor
follow-up patches based on the comments in the review as well.
Differential Revision: https://reviews.llvm.org/D24225
llvm-svn: 283982
|
| |
|
|
|
|
|
|
|
|
| |
This re-applies r283798, disabled in r283803, with the static_assert
tests disabled under MSVC. The deleted functions still seem to catch
mistakes in MSVC, so it's not a significant loss.
Part of rdar://problem/16375365
llvm-svn: 283935
|
| |
|
|
| |
llvm-svn: 283916
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM's RandomNumberGenerator wasn't compatible with
the random distribution from <random>.
Fixes PR25105
Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu>
Differential Revision: https://reviews.llvm.org/D25443
llvm-svn: 283854
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r283798, as it causes static asserts on
MSVC 2015 with the following errors:
ArrayRefTest.cpp(38): error C2338: Assigning from single prvalue element
ArrayRefTest.cpp(41): error C2338: Assigning from single xvalue element
ArrayRefTest.cpp(47): error C2338: Assigning from an initializer list
llvm-svn: 283803
|
| |
|
|
|
|
|
|
|
|
|
| |
llvm::cl already has a function called llvm::apply() so this is
causing an ODR violation. The STLExtras version should win the
vote on which one gets to be called apply() since it is named
after the equivalent STL function, but since renaiming the cl
version is more difficult, let's do this for now to get the
bots green.
llvm-svn: 283800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this, the following statements will create ArrayRefs that
refer to temporary storage that goes out of scope by the end of the
line:
someArrayRef = getSingleElement();
someArrayRef = {elem1, elem2};
Note that the constructor still has this problem:
ArrayRef<Element> someArrayRef = getSingleElement();
ArrayRef<Element> someArrayRef = {elem1, elem2};
but that's a little harder to get rid of because we want to be able to
use this in calls:
takesArrayRef(getSingleElement());
takesArrayRef({elem1, elem2});
Part of rdar://problem/16375365. Reviewed by Duncan Exon Smith.
llvm-svn: 283798
|
| |
|
|
| |
llvm-svn: 283794
|
| |
|
|
|
|
|
|
|
| |
This is equivalent to the C++14 std::apply(). Since we are not
using C++14 yet, this allows us to still make use of apply anyway.
Differential revision: https://reviews.llvm.org/D25100
llvm-svn: 283779
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25418
llvm-svn: 283765
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The keys must still be copyable, because we store two copies of them.
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25404
llvm-svn: 283764
|
| |
|
|
|
|
|
| |
This patch adds Cortex-R52, the new ARM real-time processor, to LLVM.
Cortex-R52 implements the ARMv8-R architecture.
llvm-svn: 283542
|
| |
|
|
| |
llvm-svn: 283527
|
| |
|
|
|
|
| |
Clang didn't diagnose it before. Oops.
llvm-svn: 283451
|
| |
|
|
|
|
|
|
| |
Fuchsia is a new operating system.
Differential Revision: https://reviews.llvm.org/D25116
llvm-svn: 283419
|
| |
|
|
| |
llvm-svn: 283395
|
| |
|
|
|
|
| |
Ten days.
llvm-svn: 283394
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This makes a change to the state used to maintain visited information for depth first iterator. We know assume a method "completed(...)" which is called after all children of a node have been visited. In all existing cases, this method does nothing so this patch has no functional changes. It will however allow a client to distinguish back from cross edges in a DFS tree.
Reviewers: nadav, mehdi_amini, dberlin
Subscribers: MatzeB, mzolotukhin, twoh, freik, llvm-commits
Differential Revision: https://reviews.llvm.org/D25191
llvm-svn: 283391
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Probably overlooked.
Reviewers: eugenis, dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24689
llvm-svn: 283377
|
| |
|
|
| |
llvm-svn: 283342
|
| |
|
|
|
|
|
|
|
| |
This allows you to enumerate over a range using a range-based
for while the return type contains the index of the enumeration.
Differential revision: https://reviews.llvm.org/D25124
llvm-svn: 283337
|
| |
|
|
|
|
|
| |
This reverts commit r283285 and re-commit r283275 with
a fix for format("%s", Str); where Str is a StringRef.
llvm-svn: 283298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should allow users of the library to get a range to iterate through
all the subcommands that are registered to the global parser. This
allows users to define subcommands in libraries that self-register to
have dispatch done at a different stage (like main). It allows for
writing code like the following:
for (auto *S : cl::getRegisteredSubcommands()) {
if (*S) {
// Dispatch on S->getName().
}
}
This change also contains tests that show this usage pattern.
Reviewers: zturner, dblaikie, echristo
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24489
llvm-svn: 283296
|
| |
|
|
|
|
| |
One test seems randomly broken: DebugInfo/X86/gnu-public-names.ll
llvm-svn: 283285
|
| |
|
|
|
|
|
| |
This reverts commit r283278 and re-commit r283275 with
the update to fix the build on the LLDB side.
llvm-svn: 283281
|
| |
|
|
|
|
| |
This reverts commit r283275, it broke LLDB Android debug server.
llvm-svn: 283278
|
| |
|
|
| |
llvm-svn: 283275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds write methods to StringTableBuilder so that it is
easier to change the underlying implementation.
Using the write methods, avoid creating a temporary buffer when using
mmaped output.
It also uses a more compact key in the DenseMap. Overall this produces
a slightly faster lld:
firefox
master 6.853419709
patch 6.841968912 1.00167361138x faster
chromium
master 4.297280174
patch 4.298712163 1.00033323147x slower
chromium fast
master 1.802335952
patch 1.806872459 1.00251701521x slower
the gold plugin
master 0.3247149
patch 0.321971644 1.00852017888x faster
clang
master 0.551279945
patch 0.543733194 1.01387951128x faster
llvm-as
master 0.032743458
patch 0.032143478 1.01866568391x faster
the gold plugin fsds
master 0.350814247
patch 0.348571741 1.00643341309x faster
clang fsds
master 0.6281672
patch 0.621130222 1.01132931187x faster
llvm-as fsds
master 0.030168899
patch 0.029797155 1.01247582194x faster
scylla
master 3.104222518
patch 3.059590248 1.01458766252x faster
llvm-svn: 283266
|
| |
|
|
|
|
|
|
|
| |
This adds support for CaseLower, CasesLower, StartsWithLower, and
EndsWithLower.
Differential revision: https://reviews.llvm.org/D24686
llvm-svn: 283244
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We now build MemorySSA in its ctor, instead of waiting until the user
calls MemorySSA::getWalker. This silently changed our unittests, since
we add BasicAA to AAResults *after* constructing MemorySSA (...but
before calling MemorySSA::getWalker).
None of them broke because we do most of our "did this get optimized
correctly?" tests in .ll files.
llvm-svn: 283158
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D25205
llvm-svn: 283138
|
| |
|
|
|
|
|
|
|
|
|
| |
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.
An earlier version of this change was landed as rL283057 which had a
use-after-free bug. This new version has a fix for that bug, and a (C++
unittests/) test case that would have triggered it rL283057.
llvm-svn: 283078
|
| |
|
|
|
|
|
|
|
|
|
| |
They've broken the sanitizer-bootstrap bots. Reverting while I investigate.
Original commit messages:
r283057: "[ConstantRange] Make getEquivalentICmp smarter"
r283058: "[SCEV] Rely on ConstantRange instead of custom logic; NFCI"
llvm-svn: 283062
|
| |
|
|
|
|
|
| |
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.
llvm-svn: 283057
|
| |
|
|
| |
llvm-svn: 283007
|
| |
|
|
|
|
|
| |
LLVM_ENABLE_THREADS. Include llvm-config.h explicitly in headers to make
sure that the definition is available.
llvm-svn: 282907
|
| |
|
|
|
|
|
|
| |
The CL was originally failing due to the use of some C++14
specific features, so I've removed those. Hopefully this will
satisfy the bots.
llvm-svn: 282867
|
| |
|
|
|
|
|
| |
This reverts commit r282804 as it seems to use some C++ features
that not all compilers support.
llvm-svn: 282809
|
| |
|
|
|
|
|
|
|
| |
enumerate allows you to iterate over a range by pairing the
iterator's value with its index in the enumeration. This gives
you most of the benefits of using a for loop while still allowing
the range syntax.
llvm-svn: 282804
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
llvm::join_items is similar to llvm::join, which produces a string
by concatenating a sequence of values together separated by a
given separator. But it differs in that the arguments to
llvm::join() are same-type members of a container, whereas the
arguments to llvm::join_items are arbitrary types passed into
a variadic template. The only requirement on parameters to
llvm::join_items (including for the separator themselves) is
that they be implicitly convertible to std::string or have
an overload of std::string::operator+
Differential Revision: https://reviews.llvm.org/D24880
llvm-svn: 282502
|
| |
|
|
|
|
| |
It will be used for fast fingerprinting in lld at least.
llvm-svn: 282493
|
| |
|
|
| |
llvm-svn: 282421
|
| |
|
|
|
|
|
| |
suggested at one point during code review and I deferred it to
a follow-up commit.
llvm-svn: 282383
|
| |
|
|
|
|
|
|
|
| |
a function pass nested inside of a CGSCC pass manager.
This is very similar to the previous unittest but makes sure the
invalidation logic works across all the layers here.
llvm-svn: 282378
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reinstates r280447. Original commit log:
This wasn't really well explicitly tested with a nice unittest before.
It seems good to have reasonably broken out unittests for this kind of
functionality as I'm workin go other invalidation features to make sure
none of the existing ones regress.
This still has too much duplicated code, I plan to factor that out in
a subsequent commit to use common helpers for repeated parts of this.
llvm-svn: 282377
|
| |
|
|
| |
llvm-svn: 282348
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds 4 new functions to StringRef, which can be used to
take or drop characters while a certain condition is met, or
until a certain condition is met. They are:
take_while - Return characters until a condition is not met.
take_until - Return characters until a condition is met.
drop_while - Remove characters until a condition is not met.
drop_until - Remove characters until a condition is met.
Internally, all of these functions delegate to two additional
helper functions which can be used to search for the position
of a character meeting or not meeting a condition, which are:
find_if - Find the first character matching a predicate.
find_if_not - Find the first character not matching a predicate.
Differential Revision: https://reviews.llvm.org/D24842
llvm-svn: 282346
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For AMDGPU, we have been using the operating system component of the triple
for specifying the low-level runtime that is being used. The rationale for
this is that the host operating system (e.g. Linux) is irrelevant for GPU code,
since its execution enviroment will be mostly controled by the low-level runtime
being used to execute the code.
In most cases, higher level languages have their own runtime which is
implemented on top of the low-level runtime. The kernel ABIs of each
language mostly depend on the low-level runtime, but there may be some
slight differences between languages. OpenCL for example, may append
additional arguments to the kernel in order to pass values like global
offsets or buffers for printf. OpenMP, HCC, or other languages may want
to add their own values which differ from OpenCL.
The reason for adding a new opencl environment type is to make it possible for the backend
to distinguish between the ABIs of the higher-level languages and handle them correctly.
It seems cleaner to use the enviroment component for this rather than creating a new
OS type for every combination of low-level runtime / high-level language.
Reviewers: Anastasia, chandlerc
Subscribers: whchung, pekka.jaaskelainen, wdng, yaxunl, llvm-commits
Differential Revision: https://reviews.llvm.org/D24735
llvm-svn: 282218
|