llvm-svn: 74728

llvm-svn: 74727

llvm-svn: 74726

llvm-svn: 74725

llvm-svn: 74724

llvm-svn: 74720

llvm-svn: 74719

llvm-svn: 74718

using ASTContxt allocation.

llvm-svn: 74717

directly consulting if a VarDecl is an implicit or actual parameter, a global,
etc.

llvm-svn: 74716

This will simplify the logic of StoreManagers that want to specially reason
about the values of parameters.

llvm-svn: 74715

llvm-svn: 74714

llvm-svn: 74713

llvm-svn: 74712

llvm-svn: 74711

llvm-svn: 74710

llvm-svn: 74709

llvm-svn: 74708

llvm-svn: 74707

Thanks Duncan!

llvm-svn: 74706

llvm-svn: 74705

declaration in the AST. 

The new ASTContext::getCommentForDecl function searches for a comment
that is attached to the given declaration, and returns that comment, 
which may be composed of several comment blocks.

Comments are always available in an AST. However, to avoid harming
performance, we don't actually parse the comments. Rather, we keep the
source ranges of all of the comments within a large, sorted vector,
then lazily extract comments via a binary search in that vector only
when needed (which never occurs in a "normal" compile).

Comments are written to a precompiled header/AST file as a blob of
source ranges. That blob is only lazily loaded when one requests a
comment for a declaration (this never occurs in a "normal" compile). 

The indexer testbed now supports comment extraction. When the
-point-at location points to a declaration with a Doxygen-style
comment, the indexer testbed prints the associated comment
block(s). See test/Index/comments.c for an example.

Some notes:
  - We don't actually attempt to parse the comment blocks themselves,
  beyond identifying them as Doxygen comment blocks to associate them
  with a declaration.
  - We won't find comment blocks that aren't adjacent to the
  declaration, because we start our search based on the location of
  the declaration.
  - We don't go through the necessary hops to find, for example,
  whether some redeclaration of a declaration has comments when our
  current declaration does not. Similarly, we don't attempt to
  associate a \param Foo marker in a function body comment with the
  parameter named Foo (although that is certainly possible).
  - Verification of my "no performance impact" claims is still "to be
  done".

llvm-svn: 74704

llvm-svn: 74703

llvm-svn: 74702

llvm-svn: 74701

pointing this out.

llvm-svn: 74700

we could do this, doing so requires adjusting the demanded mask and the code isn't 
doing that yet.  This fixes PR4495

llvm-svn: 74699

This was considering vector intrinsics to have cost 2, but non-vector
intrinsics to have cost 1, which is backward.

llvm-svn: 74698

llvm-svn: 74697

llvm-svn: 74696

llvm-svn: 74695

default global context, while new *InContext() APIs have been added that take a LLVMContextRef parameter.

Apologies to anyone affected by this breakage.

llvm-svn: 74694

llvm-svn: 74693

Change the meaning of predicate hasThumb2 to mean thumb2 ISA is available, not that it's in thumb mode and thumb2 is available. Added isThumb2 predicate to replace the old predicate.

llvm-svn: 74692

This fixes an llvm-gcc bootstrap problem I introduced.

llvm-svn: 74691

constant pool references that weren't getting properly rip-relative.

llvm-svn: 74689

llvm-svn: 74688

 - Test case to follow.

llvm-svn: 74687

llvm-svn: 74686

(I think).
 - We weren't properly parsing the leading parenthesized expression in something
   like 'push (4)(%eax)'.
 
 - Added ParseParenRelocatableExpression to support this. I suspect we should
   just use lookahead, though.

 - Test case to follow.

llvm-svn: 74685