value, the "add pc" must be CSE'ed at the same time. We could follow the same
approach as T2 by adding pseudo instructions that combine the ldr + "add pc".
But the better approach is to use movw + movt (which I will enable soon), so
I'll leave this as a TODO.

llvm-svn: 123949

llvm-svn: 123948

llvm-svn: 123947

llvm-svn: 123944

handling pseudo-path sensitivity, and instead
use those assertion conditions as dynamic checks.
These assertions would be violated when analyzing
a CFG where some branches where optimized away
during CFG construction because their branch
conditions could be trivially determined.

llvm-svn: 123943

The PassManager did not implement the transitivity of requiredTransitive. This
was unnoticed since 2006.

llvm-svn: 123942

llvm-svn: 123941

earlier revisions Clang was incorrectly warning
about an incomplete @implementation when a property
was getting synthesized.  This got fixed somewhere
down the line.

llvm-svn: 123939

fragile ivars if requested. This was done by changing the previous second parameter
to an options bitfield that can be populated by logical OR'ing the new 
StackFrame::ExpressionPathOption enum values together:

    typedef enum ExpressionPathOption
    {
        eExpressionPathOptionCheckPtrVsMember   = (1u << 0),
        eExpressionPathOptionsNoFragileObjcIvar = (1u << 1),
    };

So the old function was:
     lldb::ValueObjectSP
     StackFrame::GetValueForVariableExpressionPath (const char *var_expr, bool check_ptr_vs_member, Error &error);

But it is now:

    lldb::ValueObjectSP
    StackFrame::GetValueForVariableExpressionPath (const char *var_expr, uint32_t options, Error &error);

This allows the expression parser in Target::EvaluateExpression(...) to avoid
using simple frame variable expression paths when evaluating something that might
be a fragile ivar.

llvm-svn: 123938

llvm-svn: 123937

llvm-svn: 123936

llvm-svn: 123934

llvm-svn: 123933

llvm-svn: 123932

There should be no functional change from this, but I think it's simpler this
way.

llvm-svn: 123931

llvm-svn: 123930

llvm-svn: 123929

llvm-svn: 123928

- Use a more appropriate name for Owen's ARM Parser isMCR hack since the same operands can be present
 in cdp/cdp2 instructions. Also increase the hack with cdp/cdp2 instructions.
- Fix the encoding of cdp/cdp2 instructions for ARM (no thumb and thumb2 yet) and add testcases for t
hem.

llvm-svn: 123927

The value mapping gets confused about which original values have multiple new
definitions so they may need phi insertions.

This could probably be simplified by letting enterIntvBefore() take a live range
to be added following the instruction. As long as the range stays inside the
same basic block, value mapping shouldn't be a problem.

llvm-svn: 123926

llvm-svn: 123925

    rdar://problem/8875425 Found mySource->isa local variable assertion failed

has been fixed.

llvm-svn: 123924

analysis for short-circuited operations.  For branch written like "if (x && y)",
we maintain two sets of dataflow values for the outgoing
branches.  This suppresses some common false positives
for -Wuninitialized-experimental.

This change introduces some assertion failures
when running on the LLVM codebase.  WIP.

llvm-svn: 123923

vf calls, be made indirect. This patch is towards that goal.

llvm-svn: 123922

and methods defined within 'namespace X { ... }'.

llvm-svn: 123921

references. Note that we're currently failing reference binding to a
function lvalue.

llvm-svn: 123920

llvm-svn: 123919

working paper's structure. The only functional change here is that we
now handling binding to array rvalues, which we would previously reject.

llvm-svn: 123918

llvm-svn: 123917

llvm-svn: 123916

usese 100% CPU and times out, so it's annoying to run it.

llvm-svn: 123915

llvm-svn: 123914

involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.

llvm-svn: 123913

llvm-svn: 123912

auto-simplier the transform most missed by early-cse is (zext X) != 0 -> X != 0.
This patch adds this transform and some related logic to InstructionSimplify
and removes some of the logic from instcombine (unfortunately not all because
there are several situations in which instcombine can improve things by making
new instructions, whereas instsimplify is not allowed to do this).  At -O2 this
often results in more than 15% more simplifications by early-cse, and results in
hundreds of lines of bitcode being eliminated from the testsuite.  I did see some
small negative effects in the testsuite, for example a few additional instructions
in three programs.  One program, 483.xalancbmk, got an additional 35 instructions,
which seems to be due to a function getting an additional instruction and then
being inlined all over the place.

llvm-svn: 123911

llvm-svn: 123910

llvm-svn: 123909

to add/sub by doing the normal operation and then checking for overflow
afterwards. This generally relies on the DAG handling the later invalid
operations as well.

Fixes the 64-bit part of rdar://8622122 and rdar://8774702.

llvm-svn: 123908

llvm-svn: 123907

llvm-svn: 123906