llvm-svn: 209722

llvm-svn: 209721

Especially, reduce the amount of indentation if it doesn't increase
readability.

Before:
  NSMutableDictionary* dictionary = [NSMutableDictionary
      dictionaryWithDictionary:@{
                                 aaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaa,
                                 bbbbbbbbbbbbbbbbbb : bbbbb,
                                 cccccccccccccccc : ccccccccccccccc
                               }];

After:
  NSMutableDictionary* dictionary =
      [NSMutableDictionary dictionaryWithDictionary:@{
        aaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaa,
        bbbbbbbbbbbbbbbbbb : bbbbb,
        cccccccccccccccc : ccccccccccccccc
      }];

llvm-svn: 209720

[ASan/Win] Use clang rather than clang-cl by default for lit tests. Make Windows-only tests explicitly use clang-cl.

Reviewed at http://reviews.llvm.org/D3893

llvm-svn: 209719

llvm-svn: 209718

llvm-svn: 209717

llvm-svn: 209716

Add regression tests for the following transformation:

  str X, [x20]
   ...
  add x20, x20, #32
   ->
  str X, [x20], #32

with X being either w0, x0, s0, d0 or q0.

llvm-svn: 209715

llvm-svn: 209714

llvm-svn: 209713

Add an __lldb_init_module function so that importing the
lldbDataFormatters script automatically adds the formatters.

llvm-svn: 209712

Add regression tests for the following transformation:

 ldr X, [x20]
  ...
 add x20, x20, #32
  ->
 ldr X, [x20], #32

 with X being either w0, x0, s0, d0 or q0.

llvm-svn: 209711

llvm-svn: 209710

No functional changes.

llvm-svn: 209709

be performed by using Decl::isInStdNamespace or DeclContext::isStdNamespace

llvm-svn: 209708

llvm-svn: 209707

MSVC doesn't export these functions, so trying to import them doesnt' work.
Also, don't let any dll attributes on the CXXDestructorDecl influence the
thunk's linkage -- they should always be linkonce_odr.

This takes care of the FIXME's for this in Nico's tests.

Differential Revision: http://reviews.llvm.org/D3930

llvm-svn: 209706

llvm-svn: 209705

llvm-svn: 209704

llvm-svn: 209703

Allow classes to be intialized using current lldb::SB objects. This can help to import/export the current process state.

llvm-svn: 209702

llvm-svn: 209700

llvm-svn: 209699

Use more straightforward way to represent the set of instruction
ranges where the location of a user variable is defined - vector of pairs
of instructions (defining start/end of each range),
instead of a flattened vector of instructions where some instructions
are supposed to start the range, and the rest are supposed to "clobber" it.

Simplify the code which generates actual .debug_loc entries.

No functionality change.

llvm-svn: 209698

llvm-svn: 209697

llvm-svn: 209696

Instead of relying on the delinearization to infer the size of an element,
compute the element size from the base address type. This is a much more precise
way of computing the element size than before, as we would have mixed together
the size of an element with the strides of the innermost dimension.

llvm-svn: 209695

This is a corner case I have stumbled upon when dealing with ARM64 type
conversions. I was not able to extract a testcase for the community codebase to
fail on. The patch conservatively discards a division that would have ended up
in an ICE due to a type mismatch when building a multiply expression. I have
also added code to a place that builds add expressions and in which we should be
careful not to pass in operands of different types.

llvm-svn: 209694

We do not need to compute the GCD anymore after we removed the constant
coefficients from the terms: the terms are now all parametric expressions and
there is no need to recognize constant terms that divide only a subset of the
terms. We only rely on the size of the terms, i.e., the number of operands in
the multiply expressions, to sort the terms and recognize the parametric
dimensions.

llvm-svn: 209693

No functional change is intended: instead of relying on the delinearization to
come up with the base pointer as a remainder of the divisions in the
delinearization, we just compute it from the array access and use that value.
We substract the base pointer from the SCEV to be delinearized and that
simplifies the work of the delinearizer.

llvm-svn: 209692

The delinearization is needed only to remove the non linearity induced by
expressions involving multiplications of parameters and induction variables.
There is no problem in dealing with constant times parameters, or constant times
an induction variable.

For this reason, the current patch discards all constant terms and multipliers
before running the delinearization algorithm on the terms. The only thing
remaining in the term expressions are parameters and multiply expressions of
parameters: these simplified term expressions are passed to the array shape
recognizer that will not recognize constant dimensions anymore: these will be
recognized as different strides in parametric subscripts.

The only important special case of a constant dimension is the size of elements.
Instead of relying on the delinearization to infer the size of an element,
compute the element size from the base address type. This is a much more precise
way of computing the element size than before, as we would have mixed together
the size of an element with the strides of the innermost dimension.

llvm-svn: 209691

Current implementation of calculateDbgValueHistory already creates the
keys in the expected order (user variables are listed in order of appearance),
and should do so later by contract.

No functionality change.

llvm-svn: 209690

opt can handle them by itself.

llvm-svn: 209689

No functional change.

llvm-svn: 209688

llvm-svn: 209687

templates.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D3924

llvm-svn: 209686

llvm-svn: 209685

llvm-svn: 209684

I'm not sure exactly where/how we end up with an abstract DbgVariable
with a null DIE, but we do... looking into it & will add a test and/or
fix when I figure it out.

Currently shows up in selfhost or compiler-rt builds.

llvm-svn: 209683

The change from r209195 turned out to be important to avoid saving stale
modification time/expected size information in a module file when there
are 3 or more modules in a dependency chain and the bottom one is
rebuilt. So add a test for that.

rdar://problem/17038180

llvm-svn: 209682