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

<rdar://problem/11274012>

llvm-svn: 161704

llvm-svn: 161703

llvm-svn: 161702

statements.  Therefore, we can't pass the PatchedAsmString to the AsmParser
and expect things to work.

llvm-svn: 161701

regression on test/CodeGenObjC/2008-10-3-EhValue.m on non-Darwin targets.

llvm-svn: 161700

initializer list defined inside an objc class
implementation. wip

llvm-svn: 161699

llvm-svn: 161698

landingpad.  Enforce it in the verifier, and fix the regression tests to match.

llvm-svn: 161697

llvm-svn: 161696

While -Wpedantic was reasonable, -Wno-pedantic would turn off a bunch of warnings that
are on by default.  This counters the intention of this warning flag.

To fix this, -Wpedantic now includes extentions that are not on by default.  The
remaining warnings will manifest anyway, and won't accidentally get turned off
by -Wno-pedantic.

Fixes <rdar://problem/12076105>

llvm-svn: 161695

rdar://9877866
PR://13350

llvm-svn: 161694

This change is to be enabled in clang.

rdar://9877866
PR://13350

llvm-svn: 161693

with member initializer list defined inside
an objc implementation block. wip.

llvm-svn: 161692

expressions.  The syntax &MyClass::mutex is interpreted as a
pattern that matches m->mutex for any object m of type MyClass.

llvm-svn: 161691

of expressions, and better error messages.

llvm-svn: 161690

They identify the PHI predecessors in both diamonds and triangles.

llvm-svn: 161689

When a trace ends with a back-edge, include PHIs in the loop header in
the height computations. This makes the critical path through a loop
more accurate by including the latencies of the last instructions in the
loop.

llvm-svn: 161688

- if a boolean test (X86ISD::CMP or X86ISD:SUB) checks a boolean value
  generated from X86ISD::SETCC, try to simplify the boolean value
  generation and checking by reusing the original EFLAGS with proper
  condition code
- add hooks to X86 specific SETCC/BRCOND/CMOV, the major 3 places
  consuming EFLAGS

part of patches fixing PR12312

llvm-svn: 161687

llvm-svn: 161686

Instead of adding it to each individual subclass in
Targets.cpp, simply check the appropriate target
values.

Where before it was only on x86_64 and ppc64, it's now
also defined on mips64 and nvptx64.

Also add a bunch of negative tests to ensure it is *not*
defined on any other architectures while we're here.

llvm-svn: 161685

llvm-svn: 161684

TODO:
 - Handle @syncronized properties.
 - Always inline properties declared publicly (do not split the path).
This is tricky since there is no mapping from a Decl to the property in
the AST as far as I can tell.

llvm-svn: 161683

When object is allocated with alloc or init, we assume it cannot be a
subclass (currently used only for bifurcation purposes).

llvm-svn: 161682

when we don't need to split.

In some cases we know that a method cannot have a different
implementation in a subclass:
 - the class is declared in the main file (private)
 - all the method declarations (including the ones coming from super
classes) are in the main file.

This can be improved further, but might be enough for the heuristic.
(When we are too aggressive splitting the state, efficiency suffers.
When we fail to split the state coverage might suffer.)

llvm-svn: 161681

to track locksets.  This is in preparation for further changes.

llvm-svn: 161680

an invalid register.

<rdar://problem/12065366>

llvm-svn: 161679

llvm-svn: 161678

llvm-svn: 161677

llvm-svn: 161676

function-try-block occuring in objc's implementation
block. wip.

llvm-svn: 161675

llvm-svn: 161673

llvm-svn: 161668

member functions defined inside an objc class
implementation. wip.

llvm-svn: 161667