| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.
A previous patch broke that workflow, so this is making it work
again. Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces. libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.
Differential Revision: https://reviews.llvm.org/D38057
llvm-svn: 313763
|
| |
|
|
|
|
|
|
|
|
|
|
| |
test/DebugInfo/Generic/imported-name-inlined.ll
Remove unneeded attributes from test/DebugInfo/Generic/imported-name-inlined.ll because it was causing failures on pure MIPS builds.
Patch by Miloš Stojanović!
Differential Revision: https://reviews.llvm.org/D38079
llvm-svn: 313762
|
| |
|
|
|
|
| |
failure. NFC
llvm-svn: 313761
|
| |
|
|
|
|
|
|
|
|
| |
When clang is called as 'target-clang', put deduced target option at
the start of argument list so that option '--target=' specified in command
line could override it.
This change fixes PR34671.
llvm-svn: 313760
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bkramer, krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D38077
llvm-svn: 313759
|
| |
|
|
|
|
|
| |
The revision breaks buildbots:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/6694/steps/test/logs/stdio
llvm-svn: 313758
|
| |
|
|
| |
llvm-svn: 313757
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As Aaron Ballman has pointed out, that is not really correct.
So the key problem there is the invalidity of the testcase.
Revert r313747, and rework testcase in such a way, so these
details (platform-specific default enum sigdness) are
accounted for.
Also, add a C++-specific testcase.
llvm-svn: 313756
|
| |
|
|
| |
llvm-svn: 313755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Calls to onDiagnosticsReady were done concurrently before. This sometimes
led to older versions of diagnostics being reported to the user after
the newer versions.
Reviewers: klimek, bkramer, krasimir
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38032
llvm-svn: 313754
|
| |
|
|
| |
llvm-svn: 313753
|
| |
|
|
| |
llvm-svn: 313752
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
|
| |
|
|
|
|
|
|
|
| |
Fix walking over the schedule tree to collect its properties
(Number of permutable bands etc.).
Also add regression tests for these statistics.
llvm-svn: 313750
|
| |
|
|
| |
llvm-svn: 313749
|
| |
|
|
|
|
|
| |
It broke BB:
http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/9781
llvm-svn: 313748
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Hopefully fixes test-clang-msc-x64-on-i686-linux-RA build.
The underlying problem is that the enum is signed there.
Yet still, it is invalid for it to contain negative values,
so the comparison is always tautological in this case.
No differential, but related to https://reviews.llvm.org/D37629
llvm-svn: 313747
|
| |
|
|
|
|
|
|
|
|
| |
Previously jaml2obj would segfault on empty document.
(without yaml description).
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D38036
llvm-svn: 313746
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommit. Original commit was reverted because buildbots broke.
The error was only reproducible in the build with assertions.
The problem was that the diagnostic expected true/false as
bool, while it was provided as string "true"/"false".
Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?
Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper
Reviewed By: aaron.ballman
Subscribers: jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37629
llvm-svn: 313745
|
| |
|
|
| |
llvm-svn: 313744
|
| |
|
|
|
|
| |
calls (NFCI)
llvm-svn: 313743
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correctly determine when [ is part of a structured binding instead of a
lambda.
To be able to reuse the implementation already available, this patch also:
- sets the Previous link of FormatTokens in the UnwrappedLineParser
- moves the isCppStructuredBinding function into FormatToken
Before:
auto const const &&[x, y] { A *i };
After:
auto const const && [x, y]{A * i};
Fixing formatting of the type of the structured binding is still missing.
llvm-svn: 313742
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Its a PR34648 which was a segfault that happened because
we stored pointers to elements in DenseMap.
When DenseMap grows such pointers are invalidated.
Solution implemented is to keep elements by pointer
and not by value.
Differential revision: https://reviews.llvm.org/D38034
llvm-svn: 313741
|
| |
|
|
|
|
|
| |
These tests should have been included in r310697 / D34099 but apparently
I missed them.
llvm-svn: 313737
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch tries to vectorize loads of consecutive memory accesses, accessed
in non-consecutive or jumbled way. An earlier attempt was made with patch D26905
which was reverted back due to some basic issue with representing the 'use mask' of
jumbled accesses.
This patch fixes the mask representation by recording the 'use mask' in the usertree entry.
Change-Id: I9fe7f5045f065d84c126fa307ef6ebe0787296df
Reviewers: mkuper, loladiro, Ayal, zvi, danielcdh
Reviewed By: Ayal
Subscribers: mzolotukhin
Differential Revision: https://reviews.llvm.org/D36130
Commit after rebase for patch D36130
Change-Id: I8add1c265455669ef288d880f870a9522c8c08ab
llvm-svn: 313736
|
| |
|
|
| |
llvm-svn: 313735
|
| |
|
|
|
|
|
| |
It broke selfhosting.
http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/4896
llvm-svn: 313731
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes a bunch of logging-related FIXMEs.
Reviewers: bkramer, krasimir, malaperle
Reviewed By: malaperle
Subscribers: malaperle, klimek, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D37972
llvm-svn: 313730
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a function or variable has a type with no linkage (and is not extern "C"),
any use of it requires a definition within the same translation unit; the idea
is that it is not possible to define the entity elsewhere, so any such use is
necessarily an error.
There is an exception, though: some types formally have no linkage but
nonetheless can be referenced from other translation units (for example, this
happens to anonymous structures defined within inline functions). For entities
with those types, we suppress the diagnostic except under -pedantic.
llvm-svn: 313729
|
| |
|
|
| |
llvm-svn: 313728
|
| |
|
|
| |
llvm-svn: 313727
|
| |
|
|
|
|
|
|
|
| |
breakage)
Older Android API levels don't have ppoll, but LLDB works just fine,
since on Android it always uses pselect anyway.
llvm-svn: 313726
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit r313722.
It looks like compiler-rt/lib/tsan/rtl/tsan_libdispatch_mac.cc cannot be
compiled because some of the functions declared in the file do not match
the ones in the SDK headers (which are annotated with 'noescape').
llvm-svn: 313725
|
| |
|
|
|
|
|
|
| |
xop compare instructions. NFCI
If these checks fail we end up not selecting an instruction at all. So we are already relying on the immediate being checked upstream of isel. So doing the check in isel is just bloat to the isel table. Interestingly, we didn't check on the AVX512 version of the instructions anyway.
llvm-svn: 313724
|
| |
|
|
|
|
| |
Delete inliner before replacing it.
llvm-svn: 313723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32210
llvm-svn: 313722
|
| |
|
|
|
|
|
|
| |
This reverts r313717.
I closed the wrong phabricator review.
llvm-svn: 313721
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attribute informs the compiler that the annotated pointer parameter
of a function cannot escape and enables IRGen to attach attribute
'nocapture' to parameters that are annotated with the attribute. That is
the only optimization that currently takes advantage of 'noescape', but
there are other optimizations that will be added later that improves
IRGen for ObjC blocks.
rdar://problem/19886775
Differential Revision: https://reviews.llvm.org/D32520
llvm-svn: 313720
|
| |
|
|
| |
llvm-svn: 313719
|
| |
|
|
| |
llvm-svn: 313718
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
overridden methods when compiling for non-ARC.
Previously, clang would error out when compiling for ARC, but didn't
print any diagnostics when compiling for non-ARC.
This was pointed out in the patch review for attribute noescape:
https://reviews.llvm.org/D32210
llvm-svn: 313717
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also starts selecting global loads for constant address
in some cases. Some end up selecting to mubuf still, which
requires investigation.
We still get sub-optimal regalloc and extra waitcnts inserted
due to not really tracking the liveness of the separate register
halves.
llvm-svn: 313716
|
| |
|
|
|
|
| |
explicit type to resolve emit() as non-template function.
llvm-svn: 313715
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D36849
llvm-svn: 313714
|
| |
|
|
|
|
| |
Try to use a consistent naming scheme.
llvm-svn: 313713
|
| |
|
|
| |
llvm-svn: 313712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this change:
- Methods in LoopBase trip an assert if the receiver has been invalidated
- LoopBase::clear frees up the memory held the LoopBase instance
This change also shuffles things around as necessary to work with this stricter invariant.
Reviewers: chandlerc
Subscribers: mehdi_amini, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D38055
llvm-svn: 313708
|
| |
|
|
| |
llvm-svn: 313707
|
| |
|
|
|
|
| |
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/42594/
llvm-svn: 313706
|
| |
|
|
| |
llvm-svn: 313705
|