| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332549
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332548
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332547
|
| |
|
|
|
|
|
|
| |
with autoreleasing variables
Differential Revision: https://reviews.llvm.org/D46984
llvm-svn: 332546
|
| |
|
|
|
|
|
|
| |
Blocks can be matched just as well as functions or Objective-C methods.
Differential Revision: https://reviews.llvm.org/D46980
llvm-svn: 332545
|
| |
|
|
| |
llvm-svn: 332544
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some *_l functions were not available in some versions of Bionic. This CL
checks that the NDK version supports the functions, and if not, falls back
on the corresponding functions that don't take a locale.
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D46558
llvm-svn: 332543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Same as r332530, move WasmSymbol::dump to an implementation file to avoid linker
issues when the dump function is seen in the header, doesn't get eliminated, and
then linking fails because of the missing dependency.
<rdar://problem/40258137>
Reviewers: sbc100, ncw, paquette, vsk, dschuff
Subscribers: jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46985
llvm-svn: 332542
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VSOs now track dependencies for materializing symbols. Each symbol must have its
dependencies registered with the VSO prior to finalization. Usually this will
involve registering the dependencies returned in
AsynchronousSymbolQuery::ResolutionResults for queries made while linking the
symbols being materialized.
Queries against symbols are notified that a symbol is ready once it and all of
its transitive dependencies are finalized, allowing compilation work to be
broken up and moved between threads without queries returning until their
symbols fully safe to access / execute.
Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are
updated to support dependence tracking and more explicitly track responsibility
for symbols from the point of definition until they are finalized.
llvm-svn: 332541
|
| |
|
|
| |
llvm-svn: 332540
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332539
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332538
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332537
|
| |
|
|
| |
llvm-svn: 332536
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46969
llvm-svn: 332535
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332534
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332533
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we correct FP undef folding.
llvm-svn: 332532
|
| |
|
|
|
|
|
| |
It returns a pointer, not an int. This miscompiles all code that uses
the return value of fgets.
llvm-svn: 332531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r332305 added a use of llvm::wasm::toString in llvm::object::WasmSymbol::print,
which is in a header file. It also moves toString to BinaryFormat. This has the
unintended side-effect that any inclusion of Object/Wasm.h now relies on
toString, and needs to required_libraries = BinaryFormat. Thankfully most builds
don't fail with this because print just isn't used and gets eliminated, dropping
the required dependency in the process. Not all builds are so lucky.
Fix this issue by moving print to the corresponding .cpp file.
<rdar://problem/40258137>
Reviewers: sbc100, ncw, paquette
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D46977
llvm-svn: 332530
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This breaks the code which saves and restores LR, so we can't outline
without doing something more complicated for stack adjustment.
Found by inspection; we get lucky in most cases because getMemOpInfo
only handles STRWpost, not any other pre/post-increment forms. But it
hits a couple of artificial testcases in the tree.
Differential Revision: https://reviews.llvm.org/D46920
llvm-svn: 332529
|
| |
|
|
| |
llvm-svn: 332528
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46608
llvm-svn: 332527
|
| |
|
|
| |
llvm-svn: 332526
|
| |
|
|
| |
llvm-svn: 332525
|
| |
|
|
|
|
|
|
|
|
| |
As suggested by Fabian on PR37441, use PSHUFLW to extend shift amount types for use with PSRAD/PSRLD to reduce register pressure.
Some of this ideally would be done by combineTargetShuffle but its tricky to do as most of the shuffles are sharing inputs.
Differential Revision: https://reviews.llvm.org/D46959
llvm-svn: 332524
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29911
llvm-svn: 332523
|
| |
|
|
| |
llvm-svn: 332522
|
| |
|
|
| |
llvm-svn: 332521
|
| |
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/26501
llvm-svn: 332520
|
| |
|
|
|
|
|
|
|
|
| |
subscript expressions that can be simplified.
Currently, diagnoses code that calls container.data()[some_index] when the container exposes a suitable operator[]() method that can be used directly.
Patch by Shuai Wang.
llvm-svn: 332519
|
| |
|
|
| |
llvm-svn: 332518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function symbols.
The getAtom() method wasn't doing what we needed in all cases. We want
the symbols for the function which defines that section. We can compute
this easily enough and we know that we have at most one function in each
section.
Once this lands I will revert rL331412 which is no longer needed.
Fixes PR37409
Differential Revision: https://reviews.llvm.org/D46970
llvm-svn: 332517
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, `google-readability-casting` was disabled for Objective-C.
The Google Objective-C++ style allows both Objective-C and
C++ style in the same file. Since clang-tidy doesn't have a good
way to allow multiple styles per file, this disables the
check for Objective-C++.
Test Plan: New tests added. Ran tests with:
% make -j16 check-clang-tools
Before diff, confirmed tests failed:
https://reviews.llvm.org/P8081
After diff, confirrmed tests passed.
Reviewers: alexfh, Wizard, hokein, stephanemoore
Reviewed By: alexfh, Wizard, stephanemoore
Subscribers: stephanemoore, cfe-commits, bkramer, klimek
Differential Revision: https://reviews.llvm.org/D46659
llvm-svn: 332516
|
| |
|
|
|
| |
Log: http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/26399
llvm-svn: 332515
|
| |
|
|
|
|
|
|
|
| |
The cost computation assumes we do this correctly, but the actual
lowering was wrong.
Differential Revision: https://reviews.llvm.org/D46923
llvm-svn: 332514
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to unwind hardware exception stack frames,
which necessarily save every register and so need an extra column
for storing the return address. CFI for the exception handler could
then look as follows:
.globl exception_vector
exception_vector:
.cfi_startproc
.cfi_signal_frame
.cfi_return_column 32
l.addi r1, r1, -0x100
.cfi_def_cfa_offset 0x100
l.sw 0x00(r1), r2
.cfi_offset 2, 0x00-0x100
l.sw 0x04(r1), r3
.cfi_offset 3, 0x04-0x100
l.sw 0x08(r1), r4
.cfi_offset 4, 0x08-0x100
l.mfspr r3, r0, SPR_EPCR_BASE
l.sw 0x78(r1), r3
.cfi_offset 32, 0x78-0x100
l.jal exception_handler
l.nop
l.lwz r2, 0x00(r1)
l.lwz r3, 0x04(r1)
l.lwz r4, 0x08(r1)
l.jr r9
l.nop
.cfi_endproc
This register could, of course, also be accessed by the trace
callback or personality function, if so desired.
llvm-svn: 332513
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before this commit, R9, the link register, was used as PC register.
However, a stack frame may have R9 not set to PC on entry, either
because it uses a custom calling convention, or, more likely,
because this is a signal or exception stack frame. Using R9 as
PC register made it impossible to unwind such frames.
All other architectures similarly use a dedicated PC register.
llvm-svn: 332512
|
| |
|
|
|
|
| |
(https://reviews.llvm.org/D46887)
llvm-svn: 332511
|
| |
|
|
| |
llvm-svn: 332510
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template.
The added test case was triggering assertion
> Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825.
It was happening with ClassTemplateSpecializationDecl
`enable_if_not_same<int, int>`. Because this template is specialized for
equal types not to have a definition, it wasn't instantiated and its
specialization kind remained TSK_Undeclared. And because it was implicit
instantiation, we didn't mark the decl as invalid. So when we try to
find the best matching partial specialization the second time, we hit
the assertion as partial specialization is already set.
Fix by reusing stored partial specialization when available, instead of
looking for the best match every time.
rdar://problem/39524996
Reviewers: rsmith, arphaman
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46909
llvm-svn: 332509
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D46887
llvm-svn: 332508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This can be solved just in seconds with KLEE. Current libFuzzer
is able to satistfy 101 constraints out of 410 constraints presented during
the first hour of running with -use_value_profile=1 and -max_len=20.
During the next 3 hours, libFuzzer is able to generate ~50 NEW inputs,
bot none of those solve any new constraint.
During the next 20 hours, it didn't find any NEW inputs.
This test might be interesting for experimenting with the data flow tracing
approach started in https://reviews.llvm.org/D46666.
For the solution with KLEE and other information, see
https://github.com/Dor1s/codegate2017-quals-angrybird
Reviewers: kcc
Reviewed By: kcc
Subscribers: delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D46924
llvm-svn: 332507
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is needed for the continuation of D46504,
to be able to store the timings.
Reviewers: george.karpenkov, NoQ, alexfh, sbenza
Reviewed By: alexfh
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D46939
llvm-svn: 332506
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is needed for the continuation of D46504,
to be able to store the timings.
Reviewers: george.karpenkov, NoQ, alexfh, sbenza
Reviewed By: alexfh
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D46938
llvm-svn: 332505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Although this is not stricly required, i would very much prefer
not to have known random precision losses along the way.
Reviewers: george.karpenkov, NoQ, alexfh, sbenza
Reviewed By: george.karpenkov
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D46937
llvm-svn: 332504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: We have just used `.sys` suffix for the previous timer, this is clearly a typo
Reviewers: george.karpenkov, NoQ, alexfh, sbenza
Reviewed By: alexfh
Subscribers: llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D46936
llvm-svn: 332503
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It turns out that the previous code construct was not optimizing the allocation
and deallocation of batches. The class id was read as a class member (even
though a precomputed one) and nothing else was optimized. By changing the
construct this way, the compiler actually optimizes most of the allocation and
deallocation away to only work with a single class id, which not only saves some
CPU but also some code footprint.
Reviewers: alekseyshl, dvyukov
Reviewed By: dvyukov
Subscribers: dvyukov, delcypher, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D46961
llvm-svn: 332502
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we make those fixes.
llvm-svn: 332501
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to clean up the DAG floating-point undef logic.
This process is similar to how we handled integer undef
logic in D43141.
And as we did there, I'm trying to reduce the patch by
changing tests that would probably become meaningless
once we make those fixes.
llvm-svn: 332500
|