llvm-svn: 179243

[analyzer] Refactoring: better doxygen comment; renaming isTrackedFamily to isTrackedByCurrentChecker

llvm-svn: 179242

llvm-svn: 179241

Add support for the COFF relocation types IMAGE_REL_I386_DIR32NB and
IMAGE_REL_AMD64_ADDR32NB for 32- and 64-bit respectively. These are
similar to normal 4-byte relocations except that they do not include
the base address of the image.

Image-relative relocations are used for debug information (32-bit) and
SEH unwind tables (64-bit).

A new MCSymbolRef variant called 'VK_COFF_IMGREL32' is introduced to
specify such relocations. For AT&T assembly, this variant can be accessed
using the symbol suffix '@imgrel'.

llvm-svn: 179240

llvm-svn: 179239

// rdar://12379053

llvm-svn: 179238

llvm-svn: 179237

llvm-svn: 179236

llvm-svn: 179235

llvm-svn: 179234

Statements with an empty iteration domain may not have a schedule assigned by
the isl schedule optimizer. As Polly expects each statement to have a schedule,
we keep the old schedule for such statements.

This fixes http://llvm.org/PR15645`



Reported-by: Johannes Doerfert <johannesdoerfert@gmx.de>
llvm-svn: 179233

llvm-svn: 179232

Now the check is also applied to arguments for Objective-C method calls and to 'this' pointer.

llvm-svn: 179230

These changes are based on commit responses for r179135.

llvm-svn: 179229

Fixes PR13476

llvm-svn: 179228

In the simple and triangle if-conversion cases, when CopyAndPredicateBlock is
used because the to-be-predicated block has other predecessors, we need to
explicitly remove the old copied block from the successors list. Normally if
conversion relies on TII->AnalyzeBranch combined with BB->CorrectExtraCFGEdges
to cleanup the successors list, but if the predicated block contained an
un-analyzable branch (such as a now-predicated return), then this will fail.

These extra successors were causing a problem on PPC because it was causing
later passes (such as PPCEarlyReturm) to leave dead return-only basic blocks in
the code.

llvm-svn: 179227

llvm-svn: 179226

These changes are based on commit responses for r179135.

llvm-svn: 179225

llvm-svn: 179224

llvm-svn: 179223

temporarily while we work on plumbing through some changes to continue
supporting gdb on darwin.

This reverts commit r179122.

llvm-svn: 179222

[analyzer] When reporting a leak in RetainCount checker due to an early exit from init, step into init.

The heuristic here (proposed by Jordan) is that, usually, if a leak is due to an early exit from init, the allocation site will be
a call to alloc. Note that in other cases init resets self to [super init], which becomes the allocation site of the object.

llvm-svn: 179221

Compact unwind has an encoding for when we're not able to generate compact
unwind and must generate an EH frame instead. Track that, but still emit that CU
encoding.

llvm-svn: 179220

llvm-svn: 179219

just assembling a file and have passed the option.

llvm-svn: 179218

llvm-svn: 179217

-fstrict-aliasing.
rdar://13622687

llvm-svn: 179216

llvm-svn: 179215

The escaping interaction between Python and grep doesn't work on my
system.  This change fixes the tests for me.

llvm-svn: 179214

This avoids a nasty const correctness issue (AnalysisIDs are const, Pass* isn't).

llvm-svn: 179213

If anyone objects please let me know.

llvm-svn: 179212

In the X86 back end, getMemoryOperandNo() returns the offset
into the operand array of the start of the memory reference descriptor.

Additional code in EncodeInstruction provides an additional adjustment.

This patch places that additional code in a separate function,
called getOperandBias, so that any caller of getMemoryOperandNo
can also call getOperandBias.

llvm-svn: 179211

wasn't always the start of the operand.  If there was a symbol reference, then
Start pointed to that token.  It's very likely there are other places that need
to be updated.

llvm-svn: 179210

to disable following tests for Hexagon that require direct object
generation support.

DebugInfo/dwarf-public-names.ll
DebugInfo/dwarf-version.ll
DebugInfo/member-pointers.ll
DebugInfo/namespace.ll
DebugInfo/two-cus-from-same-file.ll

Fixes bug 15616 - http://llvm.org/bugs/show_bug.cgi?id=15616

llvm-svn: 179209

llvm-svn: 179208

Make the SLP store-merger less paranoid about function calls. We check for function calls when we check if it is safe to sink instructions.

llvm-svn: 179207

llvm-svn: 179206

llvm-svn: 179205

llvm-svn: 179204

I've not seen this happen in practice, and probably can't until we start
allowing decrement-counter-based conditional branches to be double predicated,
but just in case, don't allow predication of a diamond in which both sides have
ctr-defining branches. Even though the branching behavior of these can be
predicated, the counter-decrementing behavior cannot be.

llvm-svn: 179199