This was found by MSVC10's STL debug mode on a test from the test suite. Sadly
std::is_heap isn't standard so there is no way to assert this without writing
our own heap verify, which looks like overkill to me.

llvm-svn: 168885

llvm-svn: 168884

If we need to split the operand of a VSELECT, it must be the mask operand. We
split the entire VSELECT operand with EXTRACT_SUBVECTOR.

llvm-svn: 168883

Allow targets to prefer TypeSplitVector over TypePromoteInteger when computing the legalization method for vectors

For some targets, it is desirable to prefer scalarizing <N x i1> instead of promoting to a larger legal type, such as <N x i32>.

llvm-svn: 168882

This is a special case of signed relational comparison where result
only depends on the sign of x.

llvm-svn: 168881

This change ensures that shadow memory accesses have the same alignment
as corresponding app memory accesses.

llvm-svn: 168880

    
Rewrite getOriginPtr in a way that lets subsequent optimizations factor out
the common part of Shadow and Origin address calculation. Improves perf by
up to 5%.

llvm-svn: 168879

llvm-svn: 168878

llvm-svn: 168877

This was already done for memmove, where it is required for correctness.
This change improves performance by avoiding copyingthe same memory twice.
Also, the library functions are given __msan_ prefix to prevent instcombine
pass from converting them back to intrinsics.

llvm-svn: 168876

The logic was not changed, only names.

llvm-svn: 168875

llvm-svn: 168874

llvm-svn: 168873

llvm-svn: 168872

llvm-svn: 168871

ASTTests/StmtPrinterTest/StmtPrinter.TestMSIntegerLiteral: Remove i128 stuff. Conditioning-out in macro argument was not accepted on MS cl.exe.

llvm-svn: 168867

Compiler pass only.

llvm-svn: 168866

ASTTests/StmtPrinterTest/StmtPrinter.TestMSIntegerLiteral: Suppress i128 according to r168856, for now.

I think "i128", that I conditioned out, could be completely removed.
MS Compiler doesn't accept i128. We can assume no one would use i128.

llvm-svn: 168865

[asan/tsan] initialize the asan/tsan callbacks in runOnFunction as opposed to doInitialization. This is required to allow the upcoming changes in PassManager behavior

llvm-svn: 168864

llvm-svn: 168863

llvm-svn: 168862

llvm-svn: 168861

llvm-svn: 168857

'getPointerWidth(0) >= 64' test to be a method on TargetInfo, ready to be
properly cleaned up.

llvm-svn: 168856

llvm-svn: 168855

llvm-svn: 168854

inherited from the previous out-of-class declaration, and attributes on friend
function declarations are ill-formed in C++11.

llvm-svn: 168853

This saves a bit of memory.

llvm-svn: 168852

llvm-svn: 168851

Use this type for arrays of physical registers.

llvm-svn: 168850

Approved by: Eli and Michael.

llvm-svn: 168848

performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.

llvm-svn: 168847

llvm-svn: 168846

Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function.

llvm-svn: 168845

versions of UnknownAnyTy for ObjectiveC value types.
<unknown type>* makes no sense and can cause the
parser to behave very oddly.

<rdar://problem/12518999>

llvm-svn: 168844

Correctly handle IntegralToBool casts in C++ in the static analyzer.  Fixes <rdar://problem/12759044>.

llvm-svn: 168843

rdar://12771737

llvm-svn: 168841

Add an example of using the target.process.extra-startup-command to turn on debugserver logging since
we always forget how to do this...

llvm-svn: 168840

the frame and then getting the run lock.  Which means that our frame could have gotten
invalidated by stopping between the time we got the frame and assured the the target was
stopped.  Now we get the run lock first, and THEN resolve the underlying frame object.

<rdar://problem/12621607>

llvm-svn: 168838

This could cause miscompilations in targets where sub-register
composition is not always idempotent (ARM).

<rdar://problem/12758887>

llvm-svn: 168837