LLVMX86CompilationCallback2, called from inline asm.

llvm-svn: 183824

Summary:
"register" functions for the checker were caching the checker objects in a
static variable. This caused problems when the function is called with a
different CheckerManager.

Reviewers: klimek

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D955

llvm-svn: 183823

If you type help command <word> <word> <word> <missingSubCommand> (e.g. help script import or help type summary fake), you will get help on the deepest matched command word (i.e. script or type summary in the examples)
Also, reworked the logic for commands to produce their help to make it more object-oriented

llvm-svn: 183822

Fixes <rdar://problem/11224126> and PR12790.

llvm-svn: 183821

325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.

That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.

Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.

llvm-svn: 183820

llvm-svn: 183819

Make the error message here more interesting for the user

llvm-svn: 183818

llvm-svn: 183817

llvm-svn: 183816

llvm-svn: 183815

llvm-svn: 183814

AVX vectors when AVX is turned on.

Fixes <rdar://problem/10513611>.

llvm-svn: 183813

- skip the attach cases in TestRegisters.py -- caused slowness/sigabrt
- fixed log file removal function (in case test is run with -# flag)

llvm-svn: 183812

This test case was a "sanity check"/"breathing" test case at first, but
is really fragile, which impairs changes to yaml2obj.

`test/Object/yaml2obj-elf-bits-endian.test` is much more robust and
serves as an adequate sanity check.

llvm-svn: 183811

This slipped in during a hasty renaming.

llvm-svn: 183810

match the comments and what the instruction actually does. Noticed
on inspection.

llvm-svn: 183809

llvm-svn: 183808

llvm-svn: 183807

llvm-svn: 183806

- exposing new accessors: formats/format, ..., that allow you to iterate over all formatters
 e.g. sys_category = lldb.debugger.GetCategory("system").summary['char *']
- ensuring that C++-based synthetic children provider can at least print their description accurately, if nothing else

llvm-svn: 183805

llvm-svn: 183804

llvm-svn: 183803

The pass emits a call to sqrt that has attribute "read-none". This call will be
converted to an ISD::FSQRT node during DAG construction, which will turn into
a mips native sqrt instruction.
 

llvm-svn: 183802

Most clients have already been moved from Path V1 to V2. The ones using V1
now include PathV1.h explicitly.

llvm-svn: 183801

When a region header is part of a loop, then all entering edges of this region
should not come from the loop but outside the region. Otherwise, the loop may be
only partially part of the region, which would cause troubles in handling
induction variables.

Currently, we can only model induction variables that are either fully part of
the scop (loop induction variable) or induction variables that are scop-
invariant (parameter). A loop that is only partially part of the
scop causes troubles, as there is no good way to handle the induction
variable in the independent blocks pass.

Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 183800

llvm-svn: 183799

to discard regions with invalid loops before going through the contents of the
basic blocks

llvm-svn: 183798

to discard regions with invalid CFG before going through the contents of the
basic blocks

llvm-svn: 183797

I am about to move PathV2.h to Path.h.

llvm-svn: 183796

I am about to move PathV2.h to Path.h.

llvm-svn: 183795

Sign- and zero-extension folding was slightly incorrect because it wasn't checking that the shift on extensions was zero. Further, I recently added AND rd, rn, #255 as a form of 8-bit zero extension, and failed to add the folding code for it.

This patch fixes both issues.

This patch fixes both, and the test should remain the same:
  test/CodeGen/ARM/fast-isel-fold.ll

llvm-svn: 183794

Providing a Python helper SBData.CreateDataFromInt() to make an SBData out of a single integer number
It tries to use the current target, if any, for endianness and pointer size, and it picks a reasonable size on your behalf - if there is no way it can infer anything reasonable it essentially picks a 64-bit Mac as the reference model

llvm-svn: 183793

Use llvm::APFloat for formatting if a target is available. Each target when debugging has a "ASTContext" that helps us to use the correct floating point semantics. Now that APFloat supports toString we now use that. If we don't have a target, we still fall back on the old display methodology, but the important formatting should always have a target available and thus use the compiler floating point code.

Modified the test programs to use floating point constants that always will display correctly. We had some numbers that were being rounded, and now that we are using clang, we no longer round them and we get more correct results.

llvm-svn: 183792

with a string.  This case is sort of tricky because we can't modify the
StringLiteral used to represent such initializers.
We are forced to decompose the string into individual characters.

Fixes <rdar://problem/10465114>.

llvm-svn: 183791

For ARM on linux we use /proc/cpuinfo to detect the host CPU's features.
Linux derives these values without ever looking at the vendor of the
specific CPU implementation. Hence, it adds little value, if we parse
the output of /proc/cpuinfo only for certain vendors.

This patch enables us to derive the correct feature flags e.g. for Qualcomm
CPUs.

llvm-svn: 183790

Change for http://llvm-reviews.chandlerc.com/D952

Reviewers: Bigcheese

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D953

llvm-svn: 183789

COFF header is always present both in executable and in object file. PE header
is present only in executable. So the natural way to handle PE/COFF file is
treating COFF is mandatory header and PE is optional. Current data structre
does not allow it, because PE header includes COFF header. Removing COFF
header will simplify the code to handle PE/COFF files.

Reviewers: Bigcheese

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D952

llvm-svn: 183788

llvm-svn: 183787

llvm-svn: 183786

llvm-svn: 183785