Tidy up VSETCC lowering code a bit more by adding an llvm_unreachable and putting an a couple if conditions in a better order.

llvm-svn: 161746

llvm-svn: 161745

llvm-svn: 161744

llvm-svn: 161743

Remove the LowerMMXCONCAT_VECTORS function. It could never execute because there are no legal 64-bit vector types that could be used as inputs to a 128-bit concat_vectors. Remove a target specific SDNode and its patterns that become unused as a result.

llvm-svn: 161742

llvm-svn: 161741

llvm-svn: 161740

of the range. Fixes PR13581!

llvm-svn: 161739

llvm-svn: 161738

Remove unnecessary call to setOperationAction for SETCC of v2i64 under SSE42. It was already called for the same under SSE2.

llvm-svn: 161737

architecture

It broke MultiSource/Applications/JM/ldecod/ldecod on armv7 thumb O0 g and armv7
thumb O3.

llvm-svn: 161736

llvm-svn: 161735

llvm-svn: 161734

Use MVT.isXBitVector instead of EVT.isXBitVector when setting up operation actions. Compiles to smaller code.

llvm-svn: 161733

- FCMOV only supports a subset of X86 conditions. Skip boolean
  simplification if X86 condition is not valid for FCMOV.
- add a minimal test case for PR13577.

llvm-svn: 161732

Create isXBitVector methods in MVT and call them from EVT. This allows targets to call them with an MVT without needing to convert to EVT.

llvm-svn: 161731

Move setOperationAction for CONCAT_VECTORS for 256-bit vectors into loop since all 256-bit types are supported.

llvm-svn: 161730

llvm-svn: 161729

This is common e.g. when doing rip-relative addressing on x86_64.

llvm-svn: 161728

llvm-svn: 161727

llvm-svn: 161726

Add a couple default: llvm_unreachable() to some switch statements. Fix a bad message in an existing llvm_unreachable.

llvm-svn: 161725

Added a new "objc_refs" command that will track down all allocations on the heap that have the "isa" for the objective C class at offset zero. This will need to be improved to deal with KVO classes, but it is a start. It also disallows looking up a pointer value of zero since that would return way too many matches. 

llvm-svn: 161724

the currently selected thread.

<rdar://problem/10458225>

llvm-svn: 161723

Not only look for the comment near the declaration itself, but also walk the
redeclaration chain: the previous declaration might have had a documentation
comment.

llvm-svn: 161722

Remember to copy the address byte size and the byte order when copying data into a DWARF location object, or things will go wrong.

llvm-svn: 161721

Revert changes where we copied the expression locations back to using the reference into the debug info until test suite failures are resolved.

llvm-svn: 161720

llvm-svn: 161719

llvm-svn: 161718

FeatureFastUAMem for Nehalem, Westmere and Sandy Bridge.

FeatureFastUAMem is already on if we pass in nehalem or westmere as a command
argument.

rdar: 7252306
llvm-svn: 161717

Fixed an issue that could cause references the shared data for an object file to stay around longer than intended and could cause memory bloat when debugging multiple times.

llvm-svn: 161716

No functionality change.

llvm-svn: 161715

llvm-svn: 161714

Detect when there is not enough available ILP, so if-conversion can't
speculate instructions for free.

Compute the lengthening of the critical path when inserting a select
instruction that depends on the condition as well as both sides of the
if.

Reject conversions that would stretch the critical path by more than
half a mispredict penalty.

llvm-svn: 161713

llvm-svn: 161712

Trace::getResourceLength() computes the number of cycles required to
execute the trace when ignoring data dependencies. The number can be
compared to the critical path to estimate the trace ILP.

Trace::getPHIDepth() computes the data dependency depth of a PHI in a
trace successor that isn't necessarily part of the trace.

llvm-svn: 161711

This was causing a crash when we tried to re-apply a base object region to
itself. It probably also caused incorrect offset calculations in RegionStore.

PR13569 / <rdar://problem/12076683>

llvm-svn: 161710

This mostly affects pure virtual methods, but would also affect parent
methods defined inline in the header when analyzing the child's source file.

llvm-svn: 161709

This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.

When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)

This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.

void clang_analyzer_checkInlined(int);

For debugging purposes only!

llvm-svn: 161708

inside objc class implementation. // rdar://10387088

llvm-svn: 161705