flags. They are still not enable in this revision.

Added TargetInstrInfo::isZeroCost() to fix a fundamental problem with
the scheduler's model of operand latency in the selection DAG.

Generalized unit tests to work with sched-cycles.

llvm-svn: 123969

llvm-svn: 123968

llvm-svn: 123967

call (C++0x [temp.deduct.call]p3).

As part of this, start improving the reference-binding implementation
used in the computation of implicit conversion sequences (for overload
resolution) to reflect C++0x semantics. It still needs more work and
testing, of course.

llvm-svn: 123966

llvm-svn: 123965

llvm-svn: 123964

a select. A vector select is pairwise on each element so we'd need a new
condition with the right number of elements to select on. Fixes PR8994.

llvm-svn: 123963

llvm-svn: 123962

This allows us to simplify the handling for the overloadable attribute,
removing a number of FIXMEs.

llvm-svn: 123961

llvm-svn: 123960

Inheritable attributes on declarations may be inherited by any later
redeclaration at merge time.  By contrast, a non-inheritable attribute
will not be inherited by later redeclarations.  Non-inheritable
attributes may be semantically analysed early, allowing them to
influence the redeclaration/overloading process.

Before this change, the "overloadable" attribute received special
handling to be treated as non-inheritable, while all other attributes
were treated as inheritable.  This patch generalises the concept,
while removing a FIXME.  Some CUDA location attributes are also marked
as non-inheritable in order to support special overloading semantics
(to be introduced in a later patch).

The patch introduces a new Attr subclass, InheritableAttr, from
which all inheritable attributes derive.  Non-inheritable attributes
simply derive from Attr.

N.B. I did not review every attribute to determine whether it should
be marked non-inheritable.  This can be done later on an incremental
basis, as this change does not affect default functionality.

llvm-svn: 123959

This patch makes the necessary changes to TableGen to support
non-inheritable attributes.

llvm-svn: 123958

circumstances.

llvm-svn: 123957

While here, I'd like to complain about how vector is not an aggregate type
according to llvm::Type::isAggregateType(), but they're listed under aggregate
types in the LangRef and zero vectors are stored as ConstantAggregateZero.

llvm-svn: 123956

Add more reference-binding examples from the C++0x working paper, all of which seem to be working fine

llvm-svn: 123955

Improve on test case. Per Doug's comment. wip.

llvm-svn: 123954

reference to an lvalue.

llvm-svn: 123953

specification. In particular, an rvalue reference can bind to an
initializer expression that is an lvalue if the referent type and the
initializer expression type are not reference-related. This is a newer
formulation to the previous "rvalue references can never bind to
lvalues" rule.

llvm-svn: 123952

type checking based on the actual reference type we're trying to bind
the result to, rather than stripping the reference.

llvm-svn: 123950

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