This reverts commit r179836 as it seems to have caused test failures.

llvm-svn: 179840

This reverts commit r179837 as it seems to be causing test failures.

llvm-svn: 179839

Previously, the options for a breakopint or its
locations stored only the text of the breakpoint
condition (ironically, they used ClangUserExpression
as a glorified std::string) and, each time the condition
had to be evaluated in the StopInfo code, the expression
parser would be invoked via a static method to parse and
then execute the expression.

I made several changes here:

  - Each breakpoint location now has its own
    ClangUserExpressionSP containing a version of
    the breakpoint expression compiled for that exact
    location.

  - Whenever the breakpoint is hit, the breakpoint
    condition expression is simply re-run to determine
    whether to stop.

  - If the process changes (e.g., it's re-run) or
    the source code of the expression changes (we use
    a hash so as to avoid doing string comparisons)
    the ClangUserExpressionSP is re-generated.

This should improve performance of breakpoint
conditions significantly, and takes advantage of
the recent expression re-use work.

llvm-svn: 179838

More changes later for using declarations/DW_TAG_imported_declaration.

llvm-svn: 179837

Adding another CU-wide list, in this case of imported_modules (since they
should be relatively rare, it seemed better to add a list where each element
had a "context" value, rather than add a (usually empty) list to every scope).
This takes care of DW_TAG_imported_module, but to fully address PR14606 we'll
need to expand this to cover DW_TAG_imported_declaration too.

llvm-svn: 179836

Not that the DI* hierarchy is terribly type safe, but this makes the contract a
little clearer I think.

llvm-svn: 179835

When the SlotIndexes pass was introduced it was intended to support insertion
of code during register allocation. Removal of code was a minor consideration
(and raised the question of what to do about dangling SlotIndex objects pointing
to the erased index), so I opted to keep all indexes around indefinitely and
simply null out those that weren't being used.

Nowadays people are moving more code around (e.g. via HandleMove), which means
more zombie indexes. I want to start killing off indexes when we're done with
them to reclaim the resources they use up.
 

llvm-svn: 179834

llvm-svn: 179833

parser.

llvm-svn: 179832

executable -- if I do "(lldb) file ~/bin/exe" that tilde expansion needs
to take place here.

llvm-svn: 179831

llvm-svn: 179830

InstFlag has a default value of 0 and will simplify the VOP3 patterns.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 179829

llvm-svn: 179828

and made attempts to allocate memory in the process
fall back to FindSpace and just allocate memory on
the host (but with real-looking pointers, hence
FindSpace) if the process doesn't allow allocation.
This allows expressions to run on processes that don't
support allocation, like core files.

This introduces an extremely rare potential problem:
If all of the following are true:

- The Process doesn't support allocation;

- the user writes an expression that refers to an
  address that does not yet map to anything, or is
  dynamically generated (e.g., the result of calling
  a function); and

- the randomly-selected address for the static data
  for that specific expression runs into the
  address the user was expecting to work with;

then dereferencing the pointer later results
in the user seeing something unexpected.  This is
unlikely but possible; as a future piece of work,
we should have processes be able to hint to the
expression parser where it can allocate temporary data
of this kind.

llvm-svn: 179827

llvm-svn: 179826

llvm-svn: 179825

arguments in entry BBs.

llvm-svn: 179824

llvm-svn: 179823

Remove an unneeded local var, a missing return statement in kernel search code, thanks to Greg Clayton for finding these.

llvm-svn: 179822

Only add the -std=c++11 flag when needed, don't touch current flags.

llvm-svn: 179821

llvm-svn: 179820

[libclang] Introduce clang_Cursor_isVariadic, which returns non-zero if the given cursor is a variadic function or method.

rdar://13667150

llvm-svn: 179819

initialized temporaries to objc++ methods. 
// rdar://12788429

llvm-svn: 179818

If the return type is a pointer and the call returns an integer, then do the
inttoptr convertions. And vice versa.

llvm-svn: 179817

[libclang] Introduce clang_Cursor_getObjCDeclQualifiers, to query for 'ObjC Qualifiers' written next to the return and
parameter types in an ObjC method declarations.

rdar://13676977

llvm-svn: 179816

More fallout unique_ptr changes for from http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/3565.

llvm-svn: 179815

llvm-svn: 179814

AT&T dialect.  Test case for r179804 as well.
rdar://13674398 and PR13340.

llvm-svn: 179813

llvm-svn: 179811

llvm-svn: 179810

llvm-svn: 179809

llvm-svn: 179808

This seems to cause a stage-2 LLVM compile failure (by crashing TableGen); do
I'm disabling this for now.

llvm-svn: 179807

llvm-svn: 179806

After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.

llvm-svn: 179805

variant/dialect.  Addresses a FIXME in the emitMnemonicAliases function.
Use and test case to come shortly.
rdar://13688439 and part of PR13340.

llvm-svn: 179804

[libclang] Introduce clang_Cursor_getObjCPropertyAttributes to query the written attributes in a property declaration.

rdar://13684512

llvm-svn: 179803

Many PPC instructions have a so-called 'record form' which stores to a specific
condition register the result of comparing the result of the instruction with
zero (always as a signed comparison). For integer operations on PPC64, this is
always a 64-bit comparison.

This implementation is derived from the implementation in the ARM backend;
there are some differences because PPC condition registers are allocatable
virtual registers (although the record forms always use a specific one), and we
look for a matching subtraction instruction after the compare (but before the
first use) in addition to before it.

llvm-svn: 179802

expressions.  

Previously, ClangUserExpression assumed that if
there was a constant result for an expression 
then it could be determined during parsing.  In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap) 
was present.  This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run.  Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.

I have rewritten the IRInterpreter to be 
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see.  This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be 
present.

Materialization, interpretation, and dematerialization
are now all independent of parsing.  This means that
in theory we can parse expressions once and run them
many times.  I have three outstanding tasks before
shutting this down:

    - First, I will ensure that all of this works with
      core files.  Core files have a Process but do not
      allow allocating memory, which currently confuses
      materialization.

    - Second, I will make expression breakpoint 
      conditions remember their ClangUserExpression and
      re-use it.

    - Third, I will tear out all the redundant code
      (for example, materialization logic in
      ClangExpressionDeclMap) that is no longer used.

While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.  
This should be fixed.

llvm-svn: 179801

llvm-svn: 179800