llvm-svn: 182689

- Ressurect old MCDisassemble API to soften transition.
- Extend MCTargetDesc to set target specific symbolizer.

llvm-svn: 182688

llvm-svn: 182687

llvm-svn: 182686

llvm-svn: 182685

Otherwise ZB_Max returns a wrong result when sizeof(T) > sizeof(size_t).

llvm-svn: 182684

llvm-svn: 182683

llvm-svn: 182682

This is to address crash in rdar://13932308

llvm-svn: 182681

llvm-svn: 182680

llvm-svn: 182679

llvm-svn: 182678

When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.

By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.

<rdar://problem/13978414>

llvm-svn: 182677

The new edge algorithm would keep track of the previous location in each
location context, so that it could draw arrows coming in and out of each
inlined call. However, it tried to access the location of the call before
it was actually set (at the CallEnter node). This only affected
unterminated calls at the end of a path; calls with visible exit nodes
already had a valid location.

This patch ditches the location context map, since we're processing the
nodes in order anyway, and just unconditionally updates the PrevLoc
variable after popping out of an inlined call.

<rdar://problem/13983470>

llvm-svn: 182676

llvm-svn: 182675

To make this more consistent with 'getOrCreateType' & clarify the
distinction between the two. The only thing I couldn't quite communicate
in the name is that getOrCreateTypeDeclaration may actually produce a
full definition (in -fno-limit-debug-info) but the point is to call it
whenever only a declaration is needed & the implementation can choose
whether to provide a declaration or definition.

(also, unfortunately, getOrCreateType can produce declarations too - we
should sure this up by making it not do that - any caller that can
tolerate a declaration should be calling getOrCreateTypeDeclaration
instead)

llvm-svn: 182674

Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.

llvm-svn: 182673

llvm-svn: 182672

[Support][MathExtras] Add missing include and disable _BitScan{Forward,Reverse}64 on non x64 MSVC systems.

llvm-svn: 182671

[objc-arc] KnownSafe does not imply that it is safe to perform code motion across CFG edges since even if it is safe to remove RR pairs, we may still be able to move a retain/release into a loop.

rdar://13949644

llvm-svn: 182670

[objc-arc] Make sure that multiple owners is propogated correctly through the pass via the usage of a global data structure.

rdar://13750319

llvm-svn: 182669

Scalar now can make itself signed if needed.

<rdar://problem/13977632>

llvm-svn: 182668

llvm-svn: 182667

This removes a FIXME in CodeGenModule::SetLLVMFunctionAttributesForDefinition.
When a function is declared cold we can now generate the IR attribute in
addition to marking the function to be optimized for size.

I tried adding a separate CHECK in the existing test, but it was
failing.  I suppose CHECK matches one line exactly once?  This would be
a problem if the attributes are listed in a different order, though they
seem to be sorted.

llvm-svn: 182666

llvm-svn: 182665

- Fix for attach by name
- Details for register support
- Punted on i386 details as its status has drifted since this page was originally posted
- Multi-threaded target support is soon to be released on Linux
- Partial back-trace is called out since its a high-profile issue

llvm-svn: 182664

llvm-svn: 182662

llvm-svn: 182661

llvm-svn: 182660

for labels in inline assembly that aren't in the lookup tables.  E.g.,

  __asm {
   a:
   jmp a
  }

rdar://13983623

llvm-svn: 182659

Summary:
Added stack of preprocessor branching directives, and ignore all tokens
inside #if 0 except for preprocessor directives.

Reviewers: klimek, djasper

Reviewed By: klimek

CC: cfe-commits

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

llvm-svn: 182658

llvm-svn: 182657

LoopVectorize: LoopSimplify can't canonicalize loops with an indirectbr in it, don't assert on those cases.

Fixes PR16139.

llvm-svn: 182656

In GDB when "step" through generateScalarLoad and "finish" the call, the
returned value is non NULL, however when printing the value contained in
BBMap[Load] after this stmt:

  BBMap[Load] = generateScalarLoad(...);

the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1.

The only intuitive idea that I have to explain this behavior is that we are
playing with the undefined behavior of eval order of the params for the function
standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be
executed before generateScalarLoad is called.

Here are some other possible explanations from Will Dietz <w@wdtz.org>:

The error is likely due to BBMap[Load] being evaluated first (creating
a {Load -> uninitialized } entry in the DenseMap), then
generateScalarLoad eventually accesses the same element and finds it
to be NULL (DenseMap[Old])..  Offhand I'm not sure if this is
guaranteed to be NULL or if it's uninitialized and happens to be NULL.

The same issue can also go wrong in an even worse way: the second
DenseMap access can trigger a rehash and *invalidate* the an earlier
evaluated expression (for example LHS of the assignment), leading to a
crash when performing the assignment store.

llvm-svn: 182655

Discussion and rationale at
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130520/175698.html

llvm-svn: 182653

Patch by Will Wilson.

llvm-svn: 182651

which takes a first step towards symbolization of disassembled instructions.

llvm-svn: 182650

llvm-svn: 182648

Suffixing #pragma comment(lib) library names with .lib if necessary.  This matches MSVC behavior, as well as allows us to properly link libraries such as the ones provided by the MSDN examples.

llvm-svn: 182647

llvm-svn: 182646