| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Extend modernize-use-auto to cases when a variable is assigned with a cast.
e.g.
Type *Ptr1 = dynamic_cast<Type*>(Ptr2);
http://llvm.org/PR25499
Reviewers: angelgarcia, aaron.ballman, klimek, Prazek, alexfh
Subscribers: Prazek, Eugene.Zelenko, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D25316
llvm-svn: 285579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For compatibility with other compilers on the platform, allow specifying
levels of the z/Architecture instead of model names with -march. In
particular, the following aliases are now supported:
-march=arch8 equals -march=z10
-march=arch9 equals -march=z196
-march=arch10 equals -march=zEC12
-march=arch11 equals -march=z13
This parallels the equivalent (and prerequisite) LLVM change in r285577.
llvm-svn: 285578
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements two changes:
- Move processor feature definition into a new file SystemZFeatures.td,
and provide explicit lists of supported and unsupported features for
each level of the z/Architecture. This allows specifying unsupported
features in the scheduler definition files for each processor.
- Add optional aliases for the -mcpu processor names according to the
level of the z/Architecture, for compatibility with other compilers
on the platform. The supported aliases are:
-mcpu=arch8 equals -mcpu=z10
-mcpu=arch9 equals -mcpu=z196
-mcpu=arch10 equals -mcpu=zEC12
-mcpu=arch11 equals -mcpu=z13
llvm-svn: 285577
|
| |
|
|
|
|
|
|
|
|
|
| |
The LEFR/LFER pseudos are aliases for vector instructions and should
therefore be guared by FeatureVector. If they aren't, the TableGen
scheduler definition checking might complain that there is no data
for those pseudos for pre-z13 machines.
No functional change intended.
llvm-svn: 285576
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when using an instruction that is not supported on the
currently selected architecture, the LLVM assembler is likely to
diagnose an "invalid operand" instead of a "missing feature".
This is because many operands require a custom parser in order to
be processed correctly, and if an instruction is not available
according to the current feature set, the generated parser code
will also not detect the associated custom operand parsers.
Fixed by temporarily enabling all features while parsing operands.
The missing features will then be correctly detected when actually
parsing the instruction itself.
llvm-svn: 285575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM currently treats the first operand of MVCK as if it were a
regular base+index+displacement address. However, it is in fact
a base+displacement combined with a length register field.
While the two might look syntactically similar, there are two
semantic differences:
- %r0 is a valid length register, even though it cannot be used
as an index register.
- In an expression with just a single register like 0(%rX), the
register is treated as base with normal addresses, while it is
treated as the length register (with an empty base) for MVCK.
Fixed by adding a new operand parser class BDRAddr and reworking
the assembler parser to distinguish between address + length
register operands and regular addresses.
llvm-svn: 285574
|
| |
|
|
| |
llvm-svn: 285573
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Under -fno-exceptions TEST_THROW becomes abort / __builtin_abort which returns
void. This causes a type mismatch in the conditional operator when testing the
library in C++98,03,11 modes.
Use a comma operator to workaround this problem.
Differential Revision: https://reviews.llvm.org/D26147
llvm-svn: 285572
|
| |
|
|
| |
llvm-svn: 285571
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reasoning:
- ExpressionParser uses a lot of stack for these, bad in some environments.
- Our formatting algorithm is N^3 and gets really slow.
- The resulting formatting is unlikely to be any good.
- This is probably generated code we're formatting by accident.
We treat these as unparseable, and signal incomplete formatting. 50 is
an arbitrary number, I've only seen real problems from ~150 levels.
Patch by Sam McCall. Thank you.
llvm-svn: 285570
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
class X {
delete(val) {
return null;
}
* gen() {
yield[1, 2];
}
* gen() {
yield{a: 1};
}
};
After:
class X {
delete(val) {
return null;
}
* gen() {
yield [1, 2];
}
* gen() {
yield {a: 1};
}
};
llvm-svn: 285569
|
| |
|
|
| |
llvm-svn: 285568
|
| |
|
|
| |
llvm-svn: 285567
|
| |
|
|
|
|
|
| |
NFC.
Review: Ulrich Weigand.
llvm-svn: 285566
|
| |
|
|
| |
llvm-svn: 285565
|
| |
|
|
|
|
|
|
|
|
| |
There is a bug describing poor cost model for floating point operations:
Bug 29083 - [X86][SSE] Improve costs for floating point operations. This
patch is the second one in series of patches dealing with cost model.
Differential Revision: https://reviews.llvm.org/D25722
llvm-svn: 285564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit on behalf of mharoush
After LGTM and check all:
This patch enables usage of k registers in inline assembly syntax.
Adding triple
Reviewer: 1. rnk
2. delena
Differential Revision: https://reviews.llvm.org/D25011
llvm-svn: 285563
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r285441)
Note that the parsing code here is still incorrect wrt. the new draft of the
dwarf 5 spec (seconds arguments to DW_LLE_startx_length should be uleb128, not
u32). Once we have compilers actually emitting dwarf conformant with the new
spec, we'll need to revisit this and figure out the proper behavior there.
This should unbreak the linux bot.
llvm-svn: 285562
|
| |
|
|
| |
llvm-svn: 285561
|
| |
|
|
| |
llvm-svn: 285560
|
| |
|
|
|
|
|
| |
In D26098, Davide Italiano submitted a .s file instead of the .ll file
that was the last stage of the review.
llvm-svn: 285559
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D26074
llvm-svn: 285558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Setting constant address space for global constants used for memcpy-initialization of arrays.
Patch by Alexey Sotkin.
Reviewers: bader, yaxunl, Anastasia
Subscribers: cfe-commits, AlexeySotkin
Differential Revision: https://reviews.llvm.org/D25305
llvm-svn: 285557
|
| |
|
|
| |
llvm-svn: 285556
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit on behalf of mharoush
After LGTM and check all:
This patch enables usage of k registers in inline assembly syntax.
Reviewer: 1. rnk
2. delena
Differential Revision: https://reviews.llvm.org/D25011
llvm-svn: 285555
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
libcpp-no-exceptions" tests that only check exceptions and nothing else
This is a follow up of D24562.
These tests do not check anything but exceptions, so it makes sense to mark
them as UNSUPPORTED under a library built without exceptions.
Differential Revision: https://reviews.llvm.org/D26075
llvm-svn: 285550
|
| |
|
|
| |
llvm-svn: 285549
|
| |
|
|
|
|
|
|
|
| |
-fbuiltin-module-map loads the clang builtins modulemap file. (This is
equivalent to -fmodule-map-file=<resource dir>/include/module.modulemap)
Differential Revision: https://reviews.llvm.org/D25767
llvm-svn: 285548
|
| |
|
|
| |
llvm-svn: 285547
|
| |
|
|
|
|
| |
started from shuffles.
llvm-svn: 285546
|
| |
|
|
| |
llvm-svn: 285545
|
| |
|
|
|
|
|
|
|
|
| |
__builtin_alloca always uses __BIGGEST_ALIGNMENT__ for the alignment of
the allocation. __builtin_alloca_with_align allows the programmer to
specify the alignment of the allocation.
This fixes PR30658.
llvm-svn: 285544
|
| |
|
|
|
|
|
| |
Put semicolon after non-defining method declaration and a class
specialization body.
llvm-svn: 285543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Convert tests using LLDB headers to use generateSource to put the right include paths in place regardless of whether or not you're building a framework.
This also abstracted generateSource out of TestPublicAPIHeaders.py into lldbtest.py.
Reviewers: tfiala, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25887
llvm-svn: 285542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
dotest.py has a framework option that is not respected. This patch makes the framework path properly configurable via the --framework option.
This patch also adds a function to the lldbtest.Base class named "hasDarwinFramework" which allows us to not rely on the host platform to determine if a framework is present. If running on Darwin, and not building a framework, this will follow the *nix code paths which are appropriate for Darwin.
Reviewers: tfiala
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D25886
llvm-svn: 285541
|
| |
|
|
|
|
|
|
| |
shufflevectors and selects.
Unfortunately, the backend currently doesn't fold masks into the instructions correctly when they come from these shufflevectors. I'll work on that in a future commit.
llvm-svn: 285540
|
| |
|
|
|
|
| |
them with unmasked builtins and selects.
llvm-svn: 285539
|
| |
|
|
|
|
|
|
| |
Adding both 'inline' and 'always_inline' to the destructor has been contentious.
However most of the performance benefits can be gained by only adding 'inline',
and there is no reason to hold up that change while discussing the other.
llvm-svn: 285538
|
| |
|
|
| |
llvm-svn: 285537
|
| |
|
|
| |
llvm-svn: 285536
|
| |
|
|
| |
llvm-svn: 285535
|
| |
|
|
| |
llvm-svn: 285534
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support CFNumberRef and OSNumber objects, which may also be accidentally
converted to plain integers or booleans.
Enable explicit boolean casts by default in non-pedantic mode.
Improve handling for warnings inside macros.
Improve error messages.
Differential Revision: https://reviews.llvm.org/D25731
llvm-svn: 285533
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
path uses string::append to construct, append, and concatenate paths. Unfortunatly
string::append has a strong exception safety guaranteed and if it can't prove
that the iterator operations don't throw then it will allocate a temporary
string copy to append to. However this extra allocation and copy is very
undesirable for path which doesn't have the same exception guarantees.
To work around this this patch adds string::__append_forward_unsafe which exposes
the std::string::append interface for forward iterators without enforcing
that the iterator is noexcept.
llvm-svn: 285532
|
| |
|
|
|
|
|
|
|
|
|
| |
This prevent the symbols from being both externally available and hidden, which
causes them to be linked incorrectly. This is only a problem when the address
of the function is explicitly taken since it will always be inlined otherwise.
This patch fixes the issues that caused r285456 to be reverted, and can
now be reapplied.
llvm-svn: 285531
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a performance bug when constructing or appending to a path
from a string or c-string. Previously we called 'push_back' to append every
single character. This caused multiple re-allocation and copies when at most
one reallocation is necessary. The new behavior is to simply call
`string::append` so it can correctly handle reallocation.
For large strings this change is a ~4x improvement. This also makes our path
faster to construct than libstdc++'s.
llvm-svn: 285530
|
| |
|
|
| |
llvm-svn: 285529
|
| |
|
|
| |
llvm-svn: 285528
|
| |
|
|
| |
llvm-svn: 285527
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch entirely rewrites the parsing logic for paths. Unlike the previous
implementation this one stores information about the current state; For example
if we are in a trailing separator or a root separator. This avoids the need for
extra lookahead (and extra work) when incrementing or decrementing an iterator.
Roughly this gives us a 15% speedup over the previous implementation.
Unfortunately this implementation is still a lot slower than libstdc++'s.
Because libstdc++ pre-parses and splits the path upon construction their
iterators are trivial to increment/decrement. This makes libc++ lazy parsing
100x slower than libstdc++. However the pre-parsing libstdc++ causes a ton
of extra and unneeded allocations when constructing the string. For example
`path("/foo/bar/")` would require at least 5 allocations with libstdc++
whereas libc++ uses only one. The non-allocating behavior is much preferable
when you consider filesystem usages like 'exists("/foo/bar/")'.
Even then libc++'s path seems to be twice as slow to simply construct compared
to libstdc++. More investigation is needed about this.
llvm-svn: 285526
|