quadratic behavior when performing pathological merges. Fixes the core
element of PR12652.

There is only one user of addRangeFrom left: join. I'm hoping to
refactor further in a future patch and have join use this merge
operation as well.

llvm-svn: 159982

of the trick merge routines. This adds a layer of testing that was
necessary when implementing more efficient (and complex) merge logic for
this datastructure.

No functionality changed here.

llvm-svn: 159981

*errors* with fixits on them by following the recovery advised by the
fixit, but if it is a fixit on a warning, then obviously the AST 
should be for the code as-written.

llvm-svn: 159980

  void f(); // expected-note 0+ {{previous declaration is here}}
  void g(); // expected-note 0-1 {{previous declaration is here}}

The old "+" syntax is still an alias for "1+", and single numbers still work.

Patch by Andy Gibbs!

llvm-svn: 159979

// expected-warning@10 {{some text}}

The line number may be absolute (as above), or relative to the current
line by prefixing the number with either '+' or '-'.

Patch by Andy Gibbs!

llvm-svn: 159978

Patch by Andy Gibbs!

llvm-svn: 159977

back to regular type printing.

llvm-svn: 159976

Improve dynamic type resolution efficiency by looking for the type in the module that contains the vtable symbol first and only look for the first match. If we don't find anything, _then_ move on to the rest of the modules in the target and watch out for multiple matches.

llvm-svn: 159975

Some NEON instructions want to match against normal SDNodes for some
operand types and Intrinsics for others. For example, CTLZ. To enable this,
switch from explicitly requiring Intrinsic on the class templates to using
SDPatternOperator instead.

llvm-svn: 159974

TableGen has support for using an intrinics name directly in a DAG,
but this breaks down when referring to just a node, as that's
handled initializer list stuff entirely via subclassing in the
parser. That is, using an instrinsic like "(int_my_intrinsic ...)"
works fine. Using it standalone for parameterizing the operator
in such a DAG does not.

Fixing this is simple enough, as we simply declare Intrinsic
as deriving from SDPatternOperator, which is the class name
intended for exactly this purpose in TargetSelectionDAG.td.

When the intrinsic is actually used in the DAG pattern, it will
be recognized and expanded to an intrinsic_wo_chain (et. al.)
just like when it's used directly.

Incoming ARM NEON cleanup based on this and a bit of functionality
improvement after that.

llvm-svn: 159973

(per Jean-Daniel's suggestion to keep around an explanation of why
direct comparisons on ObjC literals are a bad idea)

llvm-svn: 159972

llvm-svn: 159971

[cindex.py] Make CompileCommand.arguments usage consistent with CompileCommand.directory and the rest of the python binding

Patch by David Röthlisberger

llvm-svn: 159970

obscure ways, and it isn't actually important in the real world.

llvm-svn: 159969

llvm-svn: 159968

Silence buildbot so I can figure out the right flag to put this warning under.

llvm-svn: 159967

verify this is the correct grouping.

llvm-svn: 159966

llvm-svn: 159965

llvm-svn: 159963

<rdar://problem/10613024> 

llvm-svn: 159962

llvm-svn: 159961

llvm-svn: 159960

llvm-svn: 159959

llvm-svn: 159958

Teach the DAG combiner to turn sitofp/uitofp from i1 into a conditional move, since there are only two possible values.
Previously, this would become an integer extension operation, followed by a real integer->float conversion.

llvm-svn: 159957

and similar other keywords. // rdar://10723084

llvm-svn: 159956

getCondFromSETOpc, getCondFromCMovOpc, getSETFromCond, getCMovFromCond

No functional change intended.
If we want to update the condition code of CMOV|SET|Jcc, we first analyze the
opcode to get the condition code, then update the condition code, finally
synthesize the new opcode form the new condition code.

llvm-svn: 159955

llvm-svn: 159954

Access mips register classes via MCRegisterInfo's functions instead of via the
TargetRegisterClasses defined in MipsGenRegisterInfo.inc.

llvm-svn: 159953

This patch removes ~70 lines in InstCombineLoadStoreAlloca.cpp and makes both functions a bit more aggressive than before :)
In theory, we can be more aggressive when removing an alloca than a malloc, because an alloca pointer should never escape, but we are not taking advantage of this anyway

llvm-svn: 159952

Lots of tests are using an explicit target triple w/o first checking that the
target is actually available. Add a REQUIRES clause to a bunch of them. This should
hopefully unbreak bots which don't configure w/ all targets enabled.

llvm-svn: 159949

llvm-svn: 159948

llvm-svn: 159945

from diagnostics. // rdar://9657485

llvm-svn: 159943

llvm-svn: 159942

Previously it was possible to get an infinite-loop-on-invalid with a namespace
decl within @interface. Since 'namespace' is normally a safe place to retry
top-level parsing, we just didn't consume the token.

This adds a flag that tracks whether we have temporarily left Objective-C
scope to parse a C-like declaration, and uses that to better recover from
parse problems by stopping at possible method declarations and at @end. To
fix the original problem, we do /not/ stop at 'namespace' when in an
Objective-C @interface or @protocol context (but still do in @implementation).

llvm-svn: 159941

This was a regression introduced during the CallEvent changes; a call to
FunctionDecl::hasBody was also being used to replace the decl found by
lookup with the actual definition. To keep from making this mistake again
(particularly if/when we start inlining Objective-C methods), this commit
adds a "getDefinition()" method to CallEvent, which should do the right
thing under any circumstances.

llvm-svn: 159940

Chris pointed out that while the comparison is certainly problematic
and does not have well-defined behavior, it isn't any worse than some
of the other abuses that we merely warn about and doesn't need to make
the compilation fail.

Revert the release notes change (r159766) now that this is just a new warning.

llvm-svn: 159939

Fix instruction description of VMOV (between two ARM core registers and two single-precision resiters)

llvm-svn: 159938

llvm-svn: 159937