Splitting a loop to make range checks redundant is profitable only if
the range check "never" fails. Make this fact a part of recognizing a
range check -- a branch is a range check only if it is expected to
pass (via branch_weights metadata).
Differential Revision: http://reviews.llvm.org/D7192
llvm-svn: 227249
This patch resolves part of PR21711 ( http://llvm.org/bugs/show_bug.cgi?id=21711 ).
The 'f3' test case in that report presents a situation where we have two 128-bit
stores extracted from a 256-bit source vector.
Instead of producing this:
vmovaps %xmm0, (%rdi)
vextractf128 $1, %ymm0, 16(%rdi)
This patch merges the 128-bit stores into a single 256-bit store:
vmovups %ymm0, (%rdi)
Differential Revision: http://reviews.llvm.org/D7208
llvm-svn: 227242
llvm-pdbdump is a tool which can be used to dump the contents
of Microsoft-generated PDB files. It makes use of the Microsoft
DIA SDK, which is a COM based library designed specifically for
this purpose.
The initial commit of this tool dumps the raw bytes from PDB data
streams. Future commits will dump more semantic information such
as types, symbols, source files, etc similar to the types of
information accessible via llvm-dwarfdump.
Reviewed by: Aaron Ballman, Reid Kleckner, Chandler Carruth
Differential Revision: http://reviews.llvm.org/D7153
llvm-svn: 227241
If a memory access is unaligned, emit __tsan_unaligned_read/write
callbacks instead of __tsan_read/write.
Required to change semantics of __tsan_unaligned_read/write to not do the user memory.
But since they were unused (other than through __sanitizer_unaligned_load/store) this is fine.
Fixes long standing issue 17:
https://code.google.com/p/thread-sanitizer/issues/detail?id=17
llvm-svn: 227231
If a memory access is unaligned, emit __tsan_unaligned_read/write
callbacks instead of __tsan_read/write.
Required to change semantics of __tsan_unaligned_read/write to not do the user memory.
But since they were unused (other than through __sanitizer_unaligned_load/store) this is fine.
Fixes long standing issue 17:
https://code.google.com/p/thread-sanitizer/issues/detail?id=17
llvm-svn: 227230
No other test I know shows how struct names are mangled in overloaded
intrinsic functions.
Differential Revision: http://reviews.llvm.org/D7037
llvm-svn: 227229
Support weak symbols by first looking up if there is an externally visible symbol we can find,
and only if that fails using the one in the object file we're loading.
Reviewed By: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6950
llvm-svn: 227228
Summary:
Basically all other methods that look up functions by name skip them if they are mere declarations.
Do the same in FindFunctionNamed.
Reviewers: lhames
Reviewed By: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7068
llvm-svn: 227227
he following snippet doesn't build when using gcc and libc++:
#include <string>
void f(const std::string& s) { s.begin(); }
#include <vector>
void AppendTo(const std::vector<char>& v) { v.begin(); }
The problem is that __wrap_iter has a private constructor. It lists vector<>
and basic_string<> as friends, but gcc seems to ignore this for vector<> for
some reason. Declaring vector before the friend declaration in __wrap_iter is
enough to work around this problem, so do that. With this patch, I'm able to
build chromium/android with libc++. Without it, two translation units fail to
build. (iosfwd already provides a forward declaration of basic_string.)
As far as I can tell, this is due to a gcc bug, which I filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816.
Fixes PR22355.
http://reviews.llvm.org/D7201
llvm-svn: 227226
In particular, remove the OpaqueExpr transformation from r225389 and
move the correction of the conditional from CheckConditionalOperands to
ActOnConditionalOp before the OpaqueExpr is created. This fixes the
typo correction behavior in C code that uses the GNU extension for a
binary ?: (without an expression between the "?" and the ":").
llvm-svn: 227220
This patch adds lldbmi_testcase.MiTestCaseBase class and removes
a lot of repitition in the lldb-mi test cases. Also cleans import
list and code-style.
Presented for review in http://reviews.llvm.org/D7162.
Patch from Ilia K <ki.stfu@gmail.com>.
llvm-svn: 227218
it does call, and implementing it so that we once again look up external symbols in the JIT.
Also juked the error reporting from the JIT a little bit.
This resolves:
http://llvm.org/bugs/show_bug.cgi?id=22314
llvm-svn: 227217
Summary:
When LLVM_USE_SANITIZE_COVERAGE=YES
and one of the sanitizers is used -fsanitize-coverage=3 will be added
to build flag. This will be used to run a coverage-guided fuzzer on various
llvm libraries.
Test Plan: n/a
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7116
llvm-svn: 227216
Only pseudos have patterns on them.
Also don't set the asm string for VINTRP_Pseudo. All pseudos should have empty
asm.
This matches what all other multiclasses do.
llvm-svn: 227212
This defines the SI versions only, so it shouldn't change anything.
There are no changes other than using the new multiclasses, adding missing
mayLoad/mayStore, and formatting fixes.
llvm-svn: 227208
These functions are already present in the cc_kext for arm32 and for x86 and
x86_64. It was an oversight that they were not included for arm64.
Based on a patch by Lawrence D'Anna. Thanks!
llvm-svn: 227206
This patch teaches the Instruction Combiner how to fold a cttz/ctlz followed by
a icmp plus select into a single cttz/ctlz with flag 'is_zero_undef' cleared.
Added test InstCombine/select-cmp-cttz-ctlz.ll.
llvm-svn: 227197
A flexible way of describing MSan memory layout details on various
platforms. No significant functional changes, but the memory layout
description that you get at verbosity=1 looks slightly different.
This change includes stronger sanity checks than before.
The goal of this change is to allow more than 2 application memory
ranges for https://code.google.com/p/memory-sanitizer/issues/detail?id=76.
llvm-svn: 227192
Sanjoy Das