| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 231165
|
| |
|
|
|
|
|
|
| |
Ultimately, we'll need to leave something behind to indicate which
alloca will hold the exception, but we can figure that out when it comes
time to emit the __CxxFrameHandler3 catch handler table.
llvm-svn: 231164
|
| |
|
|
| |
llvm-svn: 231163
|
| |
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D8029
llvm-svn: 231162
|
| |
|
|
|
|
|
|
| |
Debugger.h is a huge file that gets included everywhere, and
FormatManager.h brings in a ton of unnecessary stuff and doesn't
even use anything from it in the header.
llvm-svn: 231161
|
| |
|
|
|
|
| |
Binding __builtin_alloca() return value to the symbolic value kills previous binding to a AllocaRegion established by the core.BuiltinFunctions checker. Other checkers may rely upon this information. Rollback handling of __builtin_alloca() to the way prior to r229850.
llvm-svn: 231160
|
| |
|
|
| |
llvm-svn: 231159
|
| |
|
|
| |
llvm-svn: 231158
|
| |
|
|
| |
llvm-svn: 231157
|
| |
|
|
|
|
|
|
|
|
| |
Selection conditions may be vectors or scalars. Make sure InstCombine
doesn't indiscriminately assume that a select which is value dependent
on another select have identical select condition types.
This fixes PR22773.
llvm-svn: 231156
|
| |
|
|
| |
llvm-svn: 231155
|
| |
|
|
| |
llvm-svn: 231154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::promise and std::future in old version of libstdc++ are buggy.
I think that's the reason why LLD tests were flaky on Ubuntu 13
buildbots until we disabled file preloading.
In this patch, I implemented very simple future and used that in
FileArchive. Compared to std::promise and std::future, it lacks
many features, but should serve our purpose.
http://reviews.llvm.org/D8025
llvm-svn: 231153
|
| |
|
|
|
|
|
|
| |
This test doesn't provide any value (it just checks that the frontend
produces exactly one compile unit), and it certainly isn't doing what
the comment says. Noticed via IRC review of my update to it in r231083.
llvm-svn: 231152
|
| |
|
|
| |
llvm-svn: 231151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fsanitize=shift-exponent.
-fsanitize=shift is now a group that includes both these checks, so
exisiting users should not be affected.
This change introduces two new UBSan kinds that sanitize only left-hand
side and right-hand side of shift operation. In practice, invalid
exponent value (negative or too large) tends to cause more portability
problems, including inconsistencies between different compilers, crashes
and inadequeate results on non-x86 architectures etc. That is,
-fsanitize=shift-exponent failures should generally be addressed first.
As a bonus, this change simplifies CodeGen implementation for emitting left
shift (separate checks for base and exponent are now merged by the
existing generic logic in EmitCheck()), and LLVM IR for these checks
(the number of basic blocks is reduced).
llvm-svn: 231150
|
| |
|
|
|
|
|
| |
The total number of sanitizers and sanitizer groups will soon
reach 32.
llvm-svn: 231149
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register moves in a loop.
From:
int M, total;
void foo() {
int i;
for (i = 0; i < M; i++) {
total = total + i / 2;
}
}
This is the kernel loop:
.LBB0_2: # %for.body
=>This Inner Loop Header: Depth=1
movl %edx, %esi
movl %ecx, %edx
shrl $31, %edx
addl %ecx, %edx
sarl %edx
addl %esi, %edx
incl %ecx
cmpl %eax, %ecx
jl .LBB0_2
--------------------------
The first mov insn "movl %edx, %esi" could be removed if we change "addl %esi, %edx" to "addl %edx, %esi".
The IR before TwoAddressInstructionPass is:
BB#2: derived from LLVM BB %for.body
Predecessors according to CFG: BB#1 BB#2
%vreg3<def> = COPY %vreg12<kill>; GR32:%vreg3,%vreg12
%vreg2<def> = COPY %vreg11<kill>; GR32:%vreg2,%vreg11
%vreg7<def,tied1> = SHR32ri %vreg3<tied0>, 31, %EFLAGS<imp-def,dead>; GR32:%vreg7,%vreg3
%vreg8<def,tied1> = ADD32rr %vreg3<tied0>, %vreg7<kill>, %EFLAGS<imp-def,dead>; GR32:%vreg8,%vreg3,%vreg7
%vreg9<def,tied1> = SAR32r1 %vreg8<kill,tied0>, %EFLAGS<imp-def,dead>; GR32:%vreg9,%vreg8
%vreg4<def,tied1> = ADD32rr %vreg9<kill,tied0>, %vreg2<kill>, %EFLAGS<imp-def,dead>; GR32:%vreg4,%vreg9,%vreg2
%vreg5<def,tied1> = INC64_32r %vreg3<kill,tied0>, %EFLAGS<imp-def,dead>; GR32:%vreg5,%vreg3
CMP32rr %vreg5, %vreg0, %EFLAGS<imp-def>; GR32:%vreg5,%vreg0
%vreg11<def> = COPY %vreg4; GR32:%vreg11,%vreg4
%vreg12<def> = COPY %vreg5<kill>; GR32:%vreg12,%vreg5
JL_4 <BB#2>, %EFLAGS<imp-use,kill>
Now TwoAddressInstructionPass will choose vreg9 to be tied with vreg4. However, it doesn't see that there is copy from vreg4 to vreg11 and another copy from vreg11 to vreg2 inside the loop body. To remove those copies, it is necessary to choose vreg2 to be tied with vreg4 instead of vreg9. This code pattern commonly appears when there is reduction operation in a loop.
So check for a reversed copy chain and if we encounter one then we can commute the add instruction so we can avoid a copy.
Patch by Wei Mi.
http://reviews.llvm.org/D7806
llvm-svn: 231148
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This does not conceptually belongs here. Instead provide a shortcut
getModule() that provides access to the DataLayout.
Reviewers: chandlerc, echristo
Reviewed By: echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8027
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231147
|
| |
|
|
|
|
|
|
|
|
| |
I removed the copy ctor, thinking that'd be the end of it - these
iterators should be perfectly assignable even from disjoint ranges (as
any iterator would be) - exkcept that the member was const.
Unconstify it.
llvm-svn: 231146
|
| |
|
|
|
|
|
| |
No functional change here, only deletes unnecessary headers
and moves one function's body from the .h file to the .cpp.
llvm-svn: 231145
|
| |
|
|
|
|
|
| |
This way, the copy assignment operator can be used without hitting the
deprecated case in C++11.
llvm-svn: 231144
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Rule of Zero
The assertion was just checking a class invariant that's pretty easy to
verify by inspection (no mutating operations, and the two non-copy ctors
already ensure the state is maintained) so remove the explicit copy ctor
in favor of the default, thus allowing the use of the default copy
assignment operator without hitting the C++11 deprecation here.
llvm-svn: 231143
|
| |
|
|
|
|
|
|
|
| |
There's no reason to disallow assigning an iterator from one range to an
iterator that previously iterated over a disjoint range. This then
follows the Rule of Zero, allowing implicit copy construction to be used
without hitting the case that's deprecated in C++11.
llvm-svn: 231142
|
| |
|
|
|
|
|
|
| |
construction as it is deprecated in C++11 in the presence of explicit copy assignment.
See r231099 for similar issues & details in [Small]BitVector.
llvm-svn: 231141
|
| |
|
|
|
|
|
| |
http://reviews.llvm.org/D8028
rdar://20023136
llvm-svn: 231140
|
| |
|
|
| |
llvm-svn: 231139
|
| |
|
|
|
|
|
|
|
|
| |
There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.
llvm-svn: 231138
|
| |
|
|
|
|
|
|
| |
It has been part of the common functions since 1.0
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 231137
|
| |
|
|
|
|
|
|
|
|
|
| |
implicit default"
Accidentally committed a few more of these cleanup changes than
intended. Still breaking these out & tidying them up.
This reverts commit r231135.
llvm-svn: 231136
|
| |
|
|
|
|
|
|
|
|
| |
There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.
llvm-svn: 231135
|
| |
|
|
|
|
|
|
|
|
| |
There doesn't seem to be any need to assert that iterator assignment is
between iterators over the same node - if you want to reuse an iterator
variable to iterate another node, that's perfectly acceptable. Just
don't mix comparisons between iterators into disjoint sequences, as
usual.
llvm-svn: 231134
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
which is deprecated in C++11 (due to the presence of a user-declare dtor in the base class)
This type could be made copyable (= default a protected copy ctor in the
base class, and preferably make the derived class final to avoid risks
of providing a slicing copy operation to further derived classes) but it
seemed easier to avoid that complexity for a dump function that I assume
(by symmetry with ResourcePriorityQueue's dump, which was actively
buggy) not often used.
llvm-svn: 231133
|
| |
|
|
| |
llvm-svn: 231132
|
| |
|
|
|
|
|
| |
Nothing from this header file was even being referenced in
Process.h anyway, so it was a completely unnecessary include.
llvm-svn: 231131
|
| |
|
|
|
|
|
|
|
| |
Previously we had only Linux using DTPOFF for these; all X86 ELF
targets should. Fixes a side issue mentioned in PR21077.
Differential Revision: http://reviews.llvm.org/D8011
llvm-svn: 231130
|
| |
|
|
| |
llvm-svn: 231129
|
| |
|
|
|
|
|
|
| |
section gc.
Patch by Bill Rushmore.
llvm-svn: 231128
|
| |
|
|
| |
llvm-svn: 231127
|
| |
|
|
|
|
| |
type which would result in a double-delete
llvm-svn: 231126
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was landed in r231035 and reverted because it was buggy.
This is fixed version of the same change.
Summary:
This patch is an attempt at making `DenseMapIterator`s "fail-fast".
Fail-fast iterators that have been invalidated due to insertion into
the host `DenseMap` deterministically trip an assert (in debug mode)
on access, instead of non-deterministically hitting memory corruption
issues.
Reviewers: dexonsmith, dberlin, ruiu, chandlerc
Reviewed By: chandlerc
Subscribers: yaron.keren, chandlerc, llvm-commits
Differential Revision: http://reviews.llvm.org/D7931
llvm-svn: 231125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With out this patch,
"clang -help" prints "USAGE: clang-3 [options] <inputs>".
It should either print
USAGE: clang [options] <inputs>
or
USAGE: clang-3.7 [options] <inputs>
With this patch, on Linux, it prints
USAGE: clang-3.7 [options] <inputs>
On Windows, it prints
USAGE: clang.exe [options] <inputs>
llvm-svn: 231124
|
| |
|
|
| |
llvm-svn: 231123
|
| |
|
|
| |
llvm-svn: 231122
|
| |
|
|
|
|
|
|
| |
frame register before checking if there is a DWARF register number for it.
Thanks to H.J. Lu for diagnosing this and providing the testcase!
llvm-svn: 231121
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The inferior can load the library now, but the remote test is still failing
because of a module loading problem in LLDB.
Reviewers: ovyalov, sivachandra, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8038
llvm-svn: 231120
|
| |
|
|
|
|
| |
Patch from eugenis
llvm-svn: 231119
|
| |
|
|
|
|
|
|
|
|
|
|
| |
valid type for Altivec support for Power.
There are two test case updates for very basic testing. While I was editing cxx-altivec.cpp I also updated it to better match some other changes in altivec.c.
Note: "vector bool long" was not also added because its use is considered deprecated.
http://reviews.llvm.org/D7235
llvm-svn: 231118
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7865
llvm-svn: 231117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vaddudm
vsubudm
vmulesw
vmulosw
vmuleuw
vmulouw
vmuluwm
vmaxsd
vmaxud
vminsd
vminud
vcmpequd
vcmpequd.
vcmpgtsd
vcmpgtsd.
vcmpgtud
vcmpgtud.
vrld
vsld
vsrd
vsrad
Phabricator review: http://reviews.llvm.org/D7959
llvm-svn: 231115
|