We can remove dead stores in the presence of fence instructions. Fence
does not change an otherwise thread local store to visible.
reviewers: reames, dexonsmith, jfb
Differential Revision: http://reviews.llvm.org/D22001
llvm-svn: 274795
The commit reinstates r273279, which was informally approved.
Original Review: http://reviews.llvm.org/D21414
This reverts commit ca632c91aaa7cafc50942f890c49f727a046ace1.
llvm-svn: 274790
Summary:
Some unittest were not able to run in 64-bit because they need more than
2MB of stack and the default allocated stack with MSVC linker is 1MB.
Reviewers: rnk
Subscribers: wang0109, chrisha, llvm-commits, kubabrecka
Differential Revision: http://reviews.llvm.org/D22101
llvm-svn: 274785
We currently do not touch a symbol's linkage in the case where a definition
has a single copy. However, this code is effectively unnecessary: either
the definition is not exported, in which case the internalize phase sets
its linkage to internal, or it is exported, in which case we need to promote
linkage to weak. Those two cases are already handled by existing code.
I believe that the only real functional change here is in the case where we
have a single definition which does not prevail (e.g. because the definition
in a native object file prevails). In that case we now lower linkage to
available_externally following the existing code path for that case.
As a result we can remove the isExported function parameter from the
thinLTOResolveWeakForLinkerInIndex function.
Differential Revision: http://reviews.llvm.org/D21883
llvm-svn: 274784
This feature was added to solve a lookup problem in expressions when local variables
shadow ivars. That solution requires fully realizing all local variables to evaluate
any expression, and can cause significant performance problems when evaluating
expressions in frames that have many complex locals.
Until we get a better solution, this setting mitigates the problem when you don't
have local variables that shadow ivars.
<rdar://problem/27226122>
llvm-svn: 274783
Summary:
Raise an error if you're using a CUDA installation that's too old for
the requested architectures. In practice, this means that you need a
CUDA 8 install to compile for sm_6*.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21869
llvm-svn: 274781
The builtin was renamed in r274770. But __syncthreads is part of our
user-facing API, so we need to keep the name as-is.
Patch by Justin Bogner.
llvm-svn: 274780
__syncthreads was renamed to __nvvm_bar0 in r274664. But __syncthreads
is part of our user-facing API, so we need to keep the name.
This will momentarily break clang; we need a matching patch there.
Patch by Justin Bogner.
llvm-svn: 274779
``afl_driver.cpp`` currently relies on weak symbols which doesn't
work properly under macOS. For now fix the build by providing a
dummy implementation of ``LLVMFuzzerInitialize(...)``. This is just
a temporary measure until we fix ``afl_driver.cpp`` for macOS.
llvm-svn: 274778
When multiple Android devices are attached, the default behaviour of ADB
is to resolve a device number based on the presence of ANDROID_SERIAL if
the serial number is not explicitly passed by the -s parameter. This patch
emulates that behaviour in lldb's ADB platform connector
Differential Revision: http://reviews.llvm.org/D22052
llvm-svn: 274776
Summary:
This patch is adding more unittests for testing the interception
of 32-bits code.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: http://reviews.llvm.org/D22077
llvm-svn: 274775
These tests don't actually care about the internal opcode number, but have to
be updated whenever we add a new one for GlobalISel. That's bad.
llvm-svn: 274774
Summary:
This patch is fixing unittests for sanitizer memory allocator.
There was two issues:
1) The VirtualAlloc can't reserve twice a memory range.
The memory space used by the SizeClass allocator is reserved
with NoAccess and pages are commited on demand (using MmapFixedOrDie).
2) The address space is allocated using two VirtualAlloc calls. The first one
for the memory space, the second one for the AdditionnalSpace (after).
On windows, they need to be freed separately.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21900
llvm-svn: 274772
- Rename the ptx.read.* intrinsics to nvvm.read.ptx.sreg.* - some but
not all of these registers were already accessible via the nvvm
name.
- Rename ptx.bar.sync nvvm.bar.sync, to match nvvm.bar0.
There's a fair amount of code motion here, but it's all very
mechanical.
llvm-svn: 274769
Summary:
The unittest was not freeing the mapped memory.
```
Repeating all tests (iteration 1) . . .
Note: Google Test filter = Allocator.AllocatorCacheDeallocNewThread
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Allocator
[ RUN ] Allocator.AllocatorCacheDeallocNewThread
[ OK ] Allocator.AllocatorCacheDeallocNewThread (3 ms)
[----------] 1 test from Allocator (4 ms total)
[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (5 ms total)
[ PASSED ] 1 test.
Repeating all tests (iteration 2) . . .
Note: Google Test filter = Allocator.AllocatorCacheDeallocNewThread
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Allocator
[ RUN ] Allocator.AllocatorCacheDeallocNewThread
==4504==WARNING: SanitizerTool failed to mprotect 0x010000003000 (1099511640064) bytes at 0x010000000000 (error code: 48
7)
==4504==Sanitizer CHECK failed: D:/src/llvm/llvm/projects/compiler-rt/lib\sanitizer_common/sanitizer_allocator.h:329 ((kSpaceBeg)) == ((reinterpret_cast<uptr>( MmapFixedNoAccess(kSpaceBeg, TotalSpaceSize)))) (1099511627776, 0)
```
Reviewers: rnk
Subscribers: llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D22094
llvm-svn: 274764
On android M it can happen that we get a ETXTBSY, when we try to launch the inferior. Sleeping
and retrying should help us get more stable results.
llvm-svn: 274763
Summary:
A regression showed up in node.js when handling conditional calls.
Fix the regression by recognizing external symbols as a possible
operand type in CallJG.
Reviewers: koriakin
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D22054
llvm-svn: 274761
This patch introduces basic Vim integration for clang-rename tool.
For setup reference see clang-rename/tool/clang-rename.py
Patch by Kirill Bobyrev!
Differential revision: http://reviews.llvm.org/D22087
llvm-svn: 274759
Currently, to be able to process a source file including e.g. stddef.h with
clang-tidy, one has to build both clang-tidy and the clang-headers target.
Since stddef.h is needed for virtually any source file, let clang-tidy depend
on clang-headers, so that it Just Works after it has been built.
http://reviews.llvm.org/D22046
llvm-svn: 274751
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
1) The first part changes the unwinding strategy, earlier the
default unwinder was used to get 2 more stack frames and if it
failed a fallback unwinder was used. Now we try to obtain as many
frames (max 10) as we can get from default unwinder and also
fallback unwinder and use the one that gives more number of frames.
2) Normally unwindplans are assosciated with functions and the
row to be used is obtained from the offset (obtained from the low_pc
of the function symbol). Sometimes it may occur that the unwindplan
is assosciated to the complete Elf section in which case the offset
calculation would be wrong as the debugger uses the same offset originally
obtained from the function symbol. Hence this offset is recalculated.
Reviewers: tberghammer, lldb-commits, labath, jasonmolenda
Subscribers: jingham
Differential Revision: http://reviews.llvm.org/D21221
llvm-svn: 274750
This patch adds synchronization between the creation of the GCD data object and destructor’s execution. It’s far from perfect, because ideally we’d want to synchronize the destruction of the last reference (via dispatch_release) and the destructor’s execution, but intercepting objc_release is problematic.
Differential Revision: http://reviews.llvm.org/D21990
llvm-svn: 274749
Davide Italiano