| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 270981
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 270980
|
| |
|
|
|
|
| |
Also give them library visiblity while there.
llvm-svn: 270979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compression sections.)
It broke buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/13585/steps/build/logs/stdio
Initial commit message:
[llvm-mc] - Teach llvm-mc to generate zlib styled compression sections.
This patch is strongly based on previously reverted D20331.
(because of gnuutils < 2.26 does not support compressed debug sections in non zlib-gnu style)
Difference that this patch supports both zlib and zlib-gnu styles.
-compress-debug-sections option now supports next values:
-compress-debug-sections=zlib-gnu
-compress-debug-sections=zlib
-compress-debug-sections=none
Previously specifying -compress-debug-sections enabled zlib-gnu compression,
so anyone can put "-compress-debug-sections=zlib-gnu" to restore the behavior
that was before this patch for case when compression was enabled.
Differential revision: http://reviews.llvm.org/D20676
llvm-svn: 270978
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is strongly based on previously reverted D20331.
(because of gnuutils < 2.26 does not support compressed debug sections in non zlib-gnu style)
Difference that this patch supports both zlib and zlib-gnu styles.
-compress-debug-sections option now supports next values:
-compress-debug-sections=zlib-gnu
-compress-debug-sections=zlib
-compress-debug-sections=none
Previously specifying -compress-debug-sections enabled zlib-gnu compression,
so anyone can put "-compress-debug-sections=zlib-gnu" to restore the behavior
that was before this patch for case when compression was enabled.
Differential revision: http://reviews.llvm.org/D20676
llvm-svn: 270977
|
| |
|
|
|
|
| |
extension intrinsics with generic IR (llvm)
llvm-svn: 270976
|
| |
|
|
|
|
|
| |
While it might change the meaning of the comment in rare circumstances,
it is better than violating the column limit.
llvm-svn: 270975
|
| |
|
|
|
|
|
|
|
| |
It seems that suffix '@4HA' was omitted for unknown reason. It is
non-cont non-volatile 'int' type of normal variable TSS.
Differential revision: http://reviews.llvm.org/D20683
llvm-svn: 270974
|
| |
|
|
|
|
|
|
|
|
|
|
| |
generic IR (llvm)
This patch removes the llvm intrinsics VPMOVSX and (V)PMOVZX sign/zero extension intrinsics and auto-upgrades to SEXT/ZEXT calls instead. We already did this for SSE41 PMOVSX sometime ago so much of that implementation can be reused.
A companion patch (D20684) removes/auto-upgrade the clang intrinsics.
Differential Revision: http://reviews.llvm.org/D20686
llvm-svn: 270973
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cross unwinding requires larger sizes for unw_context_t and unw_cursor_t
buffers (large enough to hold the VRS of any architecture). This is not
desirable for the most common situation where libunwind is used for native
unwinding only.
This patch makes native unwinding the default build configuration. This
will start testing the tigher (compile-time) bounds of unw_context_t
and unw_cursor_t buffers for each architecture.
Change-Id: Ic61c476a75603ca4812959c233cfe56f83dc0b00
llvm-svn: 270972
|
| |
|
|
|
|
| |
FormatTest.cpp to CleanUpTest.cpp.
llvm-svn: 270971
|
| |
|
|
|
|
|
|
| |
not be multiplied by 8.
The 512-bit version was fixed recently but this was missed.
llvm-svn: 270970
|
| |
|
|
| |
llvm-svn: 270969
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20704
llvm-svn: 270968
|
| |
|
|
|
|
|
|
|
| |
This will be needed in order to consistently return an Error
to clients of the API being developed in D20268.
Differential Revision: http://reviews.llvm.org/D20550
llvm-svn: 270967
|
| |
|
|
| |
llvm-svn: 270966
|
| |
|
|
| |
llvm-svn: 270965
|
| |
|
|
| |
llvm-svn: 270964
|
| |
|
|
|
|
|
|
|
|
| |
We would previously accept `--threads=4`, but this option just turns on
threading and does not specify a number of threads.
I ran into this by accident because I was passing `--threads=<n>` but
the number didn't seem to affect anything.
llvm-svn: 270963
|
| |
|
|
| |
llvm-svn: 270962
|
| |
|
|
|
|
|
|
|
|
|
|
| |
r259714 introduces the transport method into the
URL passed to the gdb-remote stub. On debugserver,
this is not supported and prevented debugserver from
being launched by lldb-server in platform mode.
This change skips the transport method addition from
r259714 when on Apple hosts.
llvm-svn: 270961
|
| |
|
|
|
|
|
|
|
|
|
| |
Since we want to move toward zero-copy access to stream data, we
want to remove all instances of copying operations. So get rid
of some of those here.
Differential Revision: http://reviews.llvm.org/D20720
Reviewed By: ruiu
llvm-svn: 270960
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APInt::operator+(uint64_t) just forwarded to operator+(const APInt&).
Constructing the APInt for the RHS takes an allocation which isn't
required. Also, for APInt's in the slow path, operator+ would
call add() internally which iterates over both arrays of values. Instead
we can use add_1 and sub_1 which only iterate while there is something to do.
Using the memory for 'opt -O2 verify-uselistorder.lto.opt.bc -o opt.bc'
(see r236629 for details), this reduces the number of allocations from
23.9M to 22.7M.
llvm-svn: 270959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new CMake function (``add_libfuzzer_test()``) to simplify
declaration of executables for testing LibFuzzer and use it to
reorganise how tests are declared.
Note that configuration of the lit configuration files has been moved
as late as possible because we are going to need to disable some tests
for some platforms and we will need to propagate this information into
the lit configuration.
Note the code for custom mains was removed because no tests are
currently written for this and Kostya seems happy to remove this.
Differential Revision: http://reviews.llvm.org/D20706
llvm-svn: 270958
|
| |
|
|
|
|
|
|
|
|
|
|
| |
type_traits header in libstdc++ 4.8 does not define is_trivially_contructible
so the code doesn't compile with it.
In this file we are using the trait for assertion to provide a better
error message. Removing it doesn't change the meaning of the code.
Differential Revision: http://reviews.llvm.org/D20719
llvm-svn: 270957
|
| |
|
|
|
|
|
|
| |
This comment was included in Peter Collingbourne's original version of
StringError (see http://reviews.llvm.org/D20550), where it made sense. It was
accidentally copied over with the rest of the class, but no longer applies.
llvm-svn: 270956
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
objc_storeStrong can be formed from a sequence such as
%0 = tail call i8* @objc_retain(i8* %p) nounwind
%tmp = load i8*, i8** @x, align 8
store i8* %0, i8** @x, align 8
tail call void @objc_release(i8* %tmp) nounwind
The code was already looking through bitcasts for most of the values
involved, but had missed one case where the pointer operand for the
store was a bitcast. Ultimately the pointer for the load and store
have to be the same value, after stripping casts.
llvm-svn: 270955
|
| |
|
|
| |
llvm-svn: 270954
|
| |
|
|
|
|
|
|
|
|
| |
_InterlockedIncrement and _InterlockedDecrement have 'long' in their
prototypes. We assumed 'long' was the same size as an i32 which is
incorrect for other targets.
This fixes PR27892.
llvm-svn: 270953
|
| |
|
|
|
|
| |
No functional change is intended.
llvm-svn: 270952
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PDBs can be extremely large. We're already mapping the entire
PDB into the process's address space, but to make matters worse
the blocks of the PDB are not arranged contiguously. So, when
we have something like an array or a string embedded into the
stream, we have to make a copy. Since it's convenient to use
traditional data structures to iterate and manipulate these
records, we need the memory to be contiguous.
As a result of this, we were using roughly twice as much memory
as the file size of the PDB, because every stream was copied
out and re-stitched together contiguously.
This patch addresses this by improving the MappedBlockStream
to allocate from a BumpPtrAllocator only when a read requires
a discontiguous read. Furthermore, it introduces some data
structures backed by a stream which can iterate over both
fixed and variable length records of a PDB. Since everything
is backed by a stream and not a buffer, we can read almost
everything from the PDB with zero copies.
Differential Revision: http://reviews.llvm.org/D20654
Reviewed By: ruiu
llvm-svn: 270951
|
| |
|
|
|
|
|
| |
Based on a totally scientific, 30 second google search "in-" appears to be the
preferred prefix.
llvm-svn: 270950
|
| |
|
|
|
|
|
|
| |
Fixes an esan workingset-memset test failure by switching to malloc to
avoid a shadow mapping issue with mmap in certain situations that will be
fully fixed separately.
llvm-svn: 270949
|
| |
|
|
|
|
|
|
| |
StringError can be used to represent Errors that aren't recoverable based on
the error type, but that have a useful error message that can be reported to
the user or logged.
llvm-svn: 270948
|
| |
|
|
| |
llvm-svn: 270947
|
| |
|
|
|
|
|
|
| |
index.
This fixes PR27902.
llvm-svn: 270946
|
| |
|
|
|
|
| |
the main fuzzing thread, print the message in the getrusage thread and exit.
llvm-svn: 270945
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If every operands of a constant are mapping to themselves, and the
type does not change, we have an early exit as acknowledged in the
comment:
// Otherwise, we have some other constant to remap. Start by checking to see
// if all operands have an identity remapping.
However instead of checking for identity the code was checking if the
operands were mapped to the constant itself, which is rarely true.
As a consequence, the coverage report showed that the early exit was
never taken.
llvm-svn: 270944
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20712
llvm-svn: 270943
|
| |
|
|
|
|
| |
pointer to read from
llvm-svn: 270942
|
| |
|
|
|
|
|
|
| |
related to demangling, we now can enable this logging and we will be able to reproduce demangler crashes (usually due to overflowing the stack) without needing someone's project.
<rdar://problem/25221899>
llvm-svn: 270941
|
| |
|
|
| |
llvm-svn: 270940
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I was investigating an odd crash in lldb when the breakpoint site
goes to bump the hit counts of the locations it implements. I noticed
that the BreakpointLocationCollection wasn't locking itself for access and
modification. I don't see how that can cause the crash I'm seeing, but still
this is the right thing to do...
<rdar://problem/25178205>
llvm-svn: 270939
|
| |
|
|
|
|
|
|
|
| |
It belongs in the instance, since then when you change architectures it can be adjusted
appropriately.
<rdar://problem/26308079>
llvm-svn: 270938
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20707
llvm-svn: 270937
|
| |
|
|
| |
llvm-svn: 270936
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CriticalAntiDepBreaker was not correctly tracking defs of the high X86 byte
registers, leading to incorrect use of a busy register to break an
antidependence.
Fixes pr27681, and its duplicates pr27580, pr27804.
Differential Revision: http://reviews.llvm.org/D20456
llvm-svn: 270935
|
| |
|
|
| |
llvm-svn: 270934
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D20655
llvm-svn: 270933
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we need one.
We have seen cases where we have been unable to find an argument type for a function, or we find one from another language, and then we try to create a function type by calling:
lldb_private::ClangASTContext::CreateFunctionType(clang::ASTContext*, lldb_private::CompilerType const&, lldb_private::CompilerType const*, unsigned int, bool, unsigned int)
This fix will ensure that all arguments to lldb_private::ClangASTContext::CreateFunctionType() are in order by checking:
- AST is valid
- if arguments are specified we have a valid argument array
- return type is valid
- return type is a clang type
- all argument types are valid
- all argument types are clang types
If any of these fail, we return an invalid CompilerType. If we don't return an invalid type, clang will crash anyway, and LLDB must not crash even in the presence of bad or missing debug info.
<rdar://problem/25172715>
llvm-svn: 270932
|