This is common when storing to global variables.

llvm-svn: 163809

llvm-svn: 163808

Rename the flag which protects from escaped allocas, which may come from bugs in user code or in the compiler. Also, dont assert if the protection is not enabled.

llvm-svn: 163807

The current implementation does not allow more than 32 types to be properly handled with target lowering. This doubles the size to 64bit types and easily allows extension to more types.

llvm-svn: 163806

llvm-svn: 163805

llvm-svn: 163804

llvm-svn: 163803

by xoring the high-bit. This fails if the source operand is a vector because we need to negate
each of the elements in the vector.

Fix rdar://12281066 PR13813.

llvm-svn: 163802

llvm-svn: 163801

llvm-svn: 163800

Use Nick's suggestion of storing a large NULL into the GV instead of memset, which requires TargetData.

llvm-svn: 163799

llvm-svn: 163798

llvm-svn: 163797

llvm-svn: 163796

llvm-svn: 163795

Review: http://llvm-reviews.chandlerc.com/D39
llvm-svn: 163794

not what most people want -- it starts a new paragraph).

llvm-svn: 163793

llvm-svn: 163792

Stack Coloring: We have code that checks that all of the uses of allocas
are within the lifetime zone. Sometime legitimate usages of allocas are
hoisted outside of the lifetime zone. For example, GEPS may calculate the
address of a member of an allocated struct. This commit makes sure that
we only check (abort regions or assert) for instructions that read and write
memory using stack frames directly. Notice that by allowing legitimate
usages outside the lifetime zone we also stop checking for instructions
which use derivatives of allocas. We will catch less bugs in user code
and in the compiler itself.

llvm-svn: 163791

* wrap code blocks in \code ... \endcode;
* refer to parameter names in paragraphs correctly (\arg is not what most
  people want -- it starts a new paragraph).

llvm-svn: 163790

[TSan] Add initial support for buidling ThreadSanitizer runtime library with CMake (currently the only supported platfrom is 64-bit Linux). This patch makes 'clang++ -fthread-sanitizer' work for both clang in the build tree and installed clang

llvm-svn: 163789

llvm-svn: 163788

llvm-svn: 163787

[Sanitizer] don't use -Werror as default compile flag for sanitizer runtimes - people may use too many distinct/old host compilers

llvm-svn: 163784

llvm-svn: 163783

llvm-svn: 163782

passing -fretain-comments-from-system-headers.  By default, the
compiler no longer parses such documentation comments, as they
can result in a noticeable compile time/PCH slowdown.

Fixes <rdar://problem/11860820>.

llvm-svn: 163778

Patch by Brad Smith.

llvm-svn: 163777

llvm-svn: 163776

llvm-svn: 163775

Add a new compression type to ModRM table that detects when the memory modRM byte represent 8 instructions and the reg modRM byte represents up to 64 instructions. Reduces modRM table from 43k entreis to 25k entries. Based on a patch from Manman Ren.

llvm-svn: 163774

llvm-svn: 163773

<rdar://problem/12061922>

llvm-svn: 163772

These will warn under -Wformat-non-iso, and will still be rejected
outright on other platforms.

<rdar://problem/12061922>

llvm-svn: 163771

The assumption that the target address for the relocation will always be
sizeof(intptr_t) and will always contain an addend for the relocation
value is very wrong. Default to no addend for now.

rdar://12157052

llvm-svn: 163765

When comparing to the macho relocation type enum value, make sure we're only
comparing against the bits in the RelType that correspond.

llvm-svn: 163764

llvm-svn: 163763

Thanks Jordan.

llvm-svn: 163762

We don't have enough GR64_TC registers when calling a varargs function
with 6 arguments. Since %al holds the number of vector registers used,
only %r11 is available as a scratch register.

This means that addressing modes using both base and index registers
can't be folded into TCRETURNmi64.

<rdar://problem/12282281>

llvm-svn: 163761

Objective-C related to NSException.

Fixes <rdar://problem/12287498>

I debated whether or not this logic should be sunk into the CFG
itself.  It's not clear if we should, as different analyses may
wish to have different policies.  We can re-evaluate this in the
future.

llvm-svn: 163760