[CodeGenPrepare] Reapply r224351 with a fix for the assertion failure:
The type promotion helper does not support vector type, so when make
such it does not kick in in such cases.

Original commit message:
[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.

This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.

Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.

** Context **

Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.

** Motivating Example **

Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
  %ld = load i8* %addr1
  %zextld = zext i8 %ld to i32
  %ld2 = load i32* %addr2
  %add = add nsw i32 %ld2, %zextld
  %sextadd = sext i32 %add to i64
  %zexta = zext i8 %a to i32
  %addza = add nsw i32 %zexta, %zextld
  %sextaddza = sext i32 %addza to i64
  %addb = add nsw i32 %b, %zextld
  %sextaddb = sext i32 %addb to i64
  call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
  ret void
}

As it is, this IR generates the following assembly on x86_64:
[...]
  movzbl  (%rdi), %eax   # zero-extended load
  movl  (%rsi), %es      # plain load
  addl  %eax, %esi       # 32-bit add
  movslq  %esi, %rdi     # sign extend the result of add
  movzbl  %dl, %edx      # zero extend the first argument
  addl  %eax, %edx       # 32-bit add
  movslq  %edx, %rsi     # sign extend the result of add
  addl  %eax, %ecx       # 32-bit add
  movslq  %ecx, %rdx     # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.

Now, by promoting the additions to form more extended loads we would generate:
[...]
  movzbl  (%rdi), %eax   # zero-extended load
  movslq  (%rsi), %rdi   # sign-extended load
  addq  %rax, %rdi       # 64-bit add
  movzbl  %dl, %esi      # zero extend the first argument
  addq  %rax, %rsi       # 64-bit add
  movslq  %ecx, %rdx     # sign extend the second argument
  addq  %rax, %rdx       # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.

This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.

Note: The throughput numbers are similar on Sandy Bridge and Haswell.

** Proposed Solution **

To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))

The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.

** Performance **

Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar:  ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%

The results are consistent for both O3 and Os.

<rdar://problem/18310086>

llvm-svn: 224402

Add missing testcase from r224388.

llvm-svn: 224401

Add printing the LC_ENCRYPTION_INFO_64 load command with llvm-objdump’s -private-headers
and add tests for the two AArch64 binaries.

llvm-svn: 224400

PR21875: codegen for non-type template parameters of nullptr_t type

llvm-svn: 224399

[CallGraph] Make sure the edges are not missed due to re-declarations

A patch by Daniel DeFreez!

We were previously dropping edges on re-declarations. Store the
canonical declarations in the graph to ensure that different
references to the same function end up reflected with the same call graph
node.

(Note, this might lead to performance fluctuation because call graph
is used to determine the function analysis order.)

llvm-svn: 224398

Revert "[CodeGenPrepare] Move sign/zero extensions near loads using type promotion."

This reverts commit r224351. It causes assertion failures when building
ICU.

llvm-svn: 224397

Rename asan_allocator2.cc to asan_allocator.cc

llvm-svn: 224396

[ASan] Introduce SetCanPoisonMemory() function.

SetCanPoisonMemory()/CanPoisonMemory() functions are now used
instead of "poison_heap" flag to determine if ASan is allowed
to poison the shadow memory. This allows to hot-patch this
value in runtime (e.g. during ASan activation) without introducing
a data race.

llvm-svn: 224395

PR21909: Don't try (and crash) to generate debug info for explicit instantiations of explicit specializations.

llvm-svn: 224394

SelectionDAG switch lowering: use 'unsigned' to count destination popularity

SwitchInst::getNumCases() returns unsinged, so using uint64_t to count cases
seems unnecessary.

Also fix a missing CHECK in the test case.

llvm-svn: 224393

Add the ability to tag one or more breakpoints with a name.  These
names can then be used in place of breakpoint id's or breakpoint id
ranges in all the commands that operate on breakpoints.

<rdar://problem/10103959>

llvm-svn: 224392

[Hexagon] Updating doubleword shift usages to new versions.

llvm-svn: 224391

Add printing the LC_ENCRYPTION_INFO load command with llvm-objdump’s -private-headers.

llvm-svn: 224390

Linker: Drop superseded subprograms

When a function gets replaced by `ModuleLinker`, drop superseded
subprograms.  This ensures that the "first" subprogram pointing at a
function is the same one that `!dbg` references point at.

This is a stop-gap fix for PR21910.  Notably, this fixes Release+Asserts
bootstraps that are currently asserting out in
`LexicalScopes::initialize()` due to the explicit instantiations in
`lib/IR/Dominators.cpp` eventually getting replaced by -argpromotion.

llvm-svn: 224389

DR1684: a constexpr member function need not be a member of a literal class type.

llvm-svn: 224388

Fix test cases given Clang's improved location information.

llvm-svn: 224387

Try typo correction on all initialization arguments and be less
pessimistic about when to do so.

This also fixes PR21905 as the initialization argument was no longer
viewed as being type dependent due to the TypoExpr being type-cast.

llvm-svn: 224386

DebugInfo: Generalize debug info location handling

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224385

fix typo, add spaces; NFC

llvm-svn: 224384

[X86][SSE] Vector double -> float conversion memory folding (cvtpd2ps)

Added a missing memory folding relationship for the (V)CVTPD2PS instruction - we can safely fold these for stack reloads.

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

llvm-svn: 224383

Make the assert a bit stronger.

We should get no declarations in here.

llvm-svn: 224382

[Hexagon] Removing old XTYPE/BIT instructions and replacing usages.

llvm-svn: 224381

Look at whether TransformTypos returned a different Expr instead of looking at the number of uncorrected typos before and after. Correcting one typo may produce an expression with another TypoExpr in it, leading to matching counts even though a typo was corrected.

Fixes PR21925!

llvm-svn: 224380

merge consecutive loads that are offset from a base address

SelectionDAG::isConsecutiveLoad() was not detecting consecutive loads
when the first load was offset from a base address.

This patch recognizes that pattern and subtracts the offset before comparing
the second load to see if it is consecutive.

The codegen change in the new test case improves from:

vmovsd 32(%rdi), %xmm0
vmovsd 48(%rdi), %xmm1
vmovhpd 56(%rdi), %xmm1, %xmm1
vmovhpd 40(%rdi), %xmm0, %xmm0
vinsertf128 $1, %xmm1, %ymm0, %ymm0

To:

vmovups 32(%rdi), %ymm0

An existing test case is also improved from:

vmovsd (%rdi), %xmm0
vmovsd 16(%rdi), %xmm1
vmovsd 24(%rdi), %xmm2
vunpcklpd %xmm2, %xmm0, %xmm0 ## xmm0 = xmm0[0],xmm2[0]
vmovhpd 8(%rdi), %xmm1, %xmm3

To:

vmovsd (%rdi), %xmm0
vmovsd 16(%rdi), %xmm1
vmovhpd 24(%rdi), %xmm0, %xmm0
vmovhpd 8(%rdi), %xmm1, %xmm1

This patch fixes PR21771 ( http://llvm.org/bugs/show_bug.cgi?id=21771 ).

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

llvm-svn: 224379

Fix handling of invalid -O options.

We were checking the value after truncating it to a bitfield.

Thanks to Yunzhong Gao for noticing it.

llvm-svn: 224378

Fix typo in comment. NFC.

llvm-svn: 224377

Fix a bug in llvm-objdump’s -private-headers for the LC_VERSION_MIN_IPHONEOS
load command not getting printed.

llvm-svn: 224376

Add a new flag, -fspell-checking-limit=<number> to control how many times we'll do spell checking. Note that spell checking will change the produced AST, so we don't automatically change this value when someone sets -ferror-limit=. With this, merge test typo-correction-pt2.cpp into typo-correction.cpp.

Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.

llvm-svn: 224375

[Hexagon] Adding tstbit/bitclr/bitset instructions.

llvm-svn: 224374

Improve the performance of the libc++ std::map formatter. This is not the full solution to the slowness of this formatter, but it's a 5% improvement in our testcase performance, which I am not going to complain too hard about.

llvm-svn: 224373

[sanitizer] prevent function call merging for sanitizer-coverage callbacks

llvm-svn: 224372

Move -Wkeyword-macro into -pedantic, remove -Wreserved-id-macro.

As discussed on the post-commit review thread for r224012, -Wkeyword-macro fires
mostly on headers trying to set up portable defines and doesn't find much bad
stuff in practice.  But [macro.names]p2 does disallow defining or undefining
keywords, override and final, and alignas, so keep the warning but move it
into -pedantic.

-Wreserved-id-macro warns on

    #define __need_size_t

which is more or less public api for glibc headers. Since this warning isn't
motivated by a standard, remove it.

(See also r223114 for a previous follow-up to r224012.)

llvm-svn: 224371

[asan] trying to fix Mac build

llvm-svn: 224370

Put static local variables of inline functions in the function comdat.

The variable (and the GV) is only ever used if the function is. Putting it
in the function's comdat make it easier for the linker to discard them.

The motivating example is

struct S {
  static const int x;
};
// const int S::x = 42;
inline const int *f() {
  static const int y = S::x;
  return &y;
}
const int *g() { return f(); }

With S::x commented out, _ZZ1fvE1y is a variable with a guard variable
that is initialized by f.

With S::x present, _ZZ1fvE1y is a constant.

llvm-svn: 224369

Fix another use of PRIx32 that should have been PRIx64.

llvm-svn: 224368

[Hexagon] Adding bit count and twiddling instructions.

llvm-svn: 224367

Fix Win build after r224353: void function returning zero.

llvm-svn: 224366

[Hexagon] Adding asr/lsr/asl reg/imm, asl with saturation, asr with rounding.  Doubleword abs/neg/not.  Interleave and deinterleave instructions.

llvm-svn: 224365

Fixes wrong -march=aarch64 option in compiler-rt

llvm-svn: 224362

[dsymutil] Pass the verbosity flag down to the processing. NFC for now.

llvm-svn: 224361

[dsymutil] Avoid calling getStringTableData() for each symbol. NFC.

llvm-svn: 224360

x86-32: PUSHF/POPF use/def EFLAGS

Summary: As a side-quest for D6629 jvoung pointed out that I should use -verify-machineinstrs and this found a bug in x86-32's handling of EFLAGS for PUSHF/POPF. This patch fixes the use/def, and adds -verify-machineinstrs to all x86 tests which contain 'EFLAGS'. One exception: this patch leaves inline-asm-fpstack.ll as-is because it fails -verify-machineinstrs in a way unrelated to EFLAGS. This patch also modifies cmpxchg-clobber-flags.ll along the lines of what D6629 already does by also testing i386.

Test Plan: ninja check

Reviewers: t.p.northover, jvoung

Subscribers: llvm-commits

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

llvm-svn: 224359

Consider calls from implict host device functions as valid in SemaCUDA.

In SemaCUDA all implicit functions were considered host device, this led to
errors such as the following code snippet failing to compile:

struct Copyable {
  const Copyable& operator=(const Copyable& x) { return *this; }
};

struct Simple {
  Copyable b;
};

void foo() {
  Simple a, b;

  a = b;
}

Above the implicit copy assignment operator was inferred as host device but
there was only a host assignment copy defined which is an error in device
compilation mode.

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

llvm-svn: 224358

Use the object's package to mangle method names, rather than the receiver's package

If we use the receiver's package, we can end up with identical manglings
for different functions. Consider:

package p
type U struct{}
func (U) f()

package q
import "p"
type T struct { p.U }
func (T) f()

The method set of *T has two synthetic methods named (*T).f(); one forwards to
(T).f(), and the other to (U).f(). Previously, we were distinguishing them
by the receiver's package, and in this case because both methods have the
same receiver, they received the same name.

The methods are correctly distinguished by the package owning the identifier
"f", which is available via f.Object().Pkg().

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

llvm-svn: 224357

Use CastInst::castIsValid to simplify the verifier.

Also delete a dead member variable.

llvm-svn: 224356

NVPTX: Remove duplicate of AsmPrinter::lowerConstant

llvm-svn: 224355

Move lowerConstant to AsmPrinter

This was a static function before, and NVPTX duplicated it
because it wasn't exposed.

llvm-svn: 224354

[asan] new flag: hard_rss_limit_mb

llvm-svn: 224353

In C++, it's #include not #import

llvm-svn: 224352

[CodeGenPrepare] Move sign/zero extensions near loads using type promotion.

This patch extends the optimization in CodeGenPrepare that moves a sign/zero
extension near a load when the target can combine them. The optimization may
promote any operations between the extension and the load to make that possible.

Although this optimization may be beneficial for all targets, in particular
AArch64, this is enabled for X86 only as I have not benchmarked it for other
targets yet.

** Context **

Most targets feature extended loads, i.e., loads that perform a zero or sign
extension for free. In that context it is interesting to expose such pattern in
CodeGenPrepare so that the instruction selection pass can form such loads.
Sometimes, this pattern is blocked because of instructions between the load and
the extension. When those instructions are promotable to the extended type, we
can expose this pattern.

** Motivating Example **

Let us consider an example:
define void @foo(i8* %addr1, i32* %addr2, i8 %a, i32 %b) {
  %ld = load i8* %addr1
  %zextld = zext i8 %ld to i32
  %ld2 = load i32* %addr2
  %add = add nsw i32 %ld2, %zextld
  %sextadd = sext i32 %add to i64
  %zexta = zext i8 %a to i32
  %addza = add nsw i32 %zexta, %zextld
  %sextaddza = sext i32 %addza to i64
  %addb = add nsw i32 %b, %zextld
  %sextaddb = sext i32 %addb to i64
  call void @dummy(i64 %sextadd, i64 %sextaddza, i64 %sextaddb)
  ret void
}

As it is, this IR generates the following assembly on x86_64:
[...]
  movzbl  (%rdi), %eax   # zero-extended load
  movl  (%rsi), %es      # plain load
  addl  %eax, %esi       # 32-bit add
  movslq  %esi, %rdi     # sign extend the result of add
  movzbl  %dl, %edx      # zero extend the first argument
  addl  %eax, %edx       # 32-bit add
  movslq  %edx, %rsi     # sign extend the result of add
  addl  %eax, %ecx       # 32-bit add
  movslq  %ecx, %rdx     # sign extend the result of add
[...]
The throughput of this sequence is 7.45 cycles on Ivy Bridge according to IACA.

Now, by promoting the additions to form more extended loads we would generate:
[...]
  movzbl  (%rdi), %eax   # zero-extended load
  movslq  (%rsi), %rdi   # sign-extended load
  addq  %rax, %rdi       # 64-bit add
  movzbl  %dl, %esi      # zero extend the first argument
  addq  %rax, %rsi       # 64-bit add
  movslq  %ecx, %rdx     # sign extend the second argument
  addq  %rax, %rdx       # 64-bit add
[...]
The throughput of this sequence is 6.15 cycles on Ivy Bridge according to IACA.

This kind of sequences happen a lot on code using 32-bit indexes on 64-bit
architectures.

Note: The throughput numbers are similar on Sandy Bridge and Haswell.

** Proposed Solution **

To avoid the penalty of all these sign/zero extensions, we merge them in the
loads at the beginning of the chain of computation by promoting all the chain of
computation on the extended type. The promotion is done if and only if we do not
introduce new extensions, i.e., if we do not degrade the code quality.
To achieve this, we extend the existing “move ext to load” optimization with the
promotion mechanism introduced to match larger patterns for addressing mode
(r200947).
The idea of this extension is to perform the following transformation:
ext(promotableInst1(...(promotableInstN(load))))
=>
promotedInst1(...(promotedInstN(ext(load))))

The promotion mechanism in that optimization is enabled by a new TargetLowering
switch, which is off by default. In other words, by default, the optimization
performs the “move ext to load” optimization as it was before this patch.

** Performance **

Configuration: x86_64: Ivy Bridge fixed at 2900MHz running OS X 10.10.
Tested Optimization Levels: O3/Os
Tests: llvm-testsuite + externals.
Results:
- No regression beside noise.
- Improvements:
CINT2006/473.astar:  ~2%
Benchmarks/PAQ8p: ~2%
Misc/perlin: ~3%

The results are consistent for both O3 and Os.

<rdar://problem/18310086>

llvm-svn: 224351

Fix the arm build bots for a test that was added.  A printing routine was incorrectly using PRIx32
when it should have been using PRIx64 for the value that was passed as uint64_t .

llvm-svn: 224350

[AVX512] Enable integer arithmetic lowering for AVX512BW/VL subsets.
Added lowering tests.

llvm-svn: 224349

On behalf of Matthew Wahab:

An instruction alias defined with InstAlias and an optional operand in the
middle of the AsmString field, "..${a} <operands>", would get the final
"}" printed in the instruction disassembly. This wouldn't happen if the optional
operand appeared as the last item in the AsmString which is how the current
backends avoided the problem.

There don't appear to be any tests for this part of Tablegen but it passes the
pre-commit tests. Manually tested the change by enabling the generic alias
printer in the ARM backend and checking the output.

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

llvm-svn: 224348

[MC] Reset the MCInst in the matcher function before adding opcode/operands.

On X86, the Intel asm parser tries to match all memory operand sizes when
none is explicitly specified.  For LEA, which doesn't really have a memory
operand (just a pointer one), this results in multiple successful matches,
one for each memory size.  There's no error because it's same opcode, so
really, it's just one match.  However, the tablegen'd matcher function
adds opcode/operands to the passed MCInst, and this results in multiple
duplicated operands.

This commit clears the MCInst in the tablegen'd matcher function.
We sometimes clear it when the match failed, so there's no expectation of
keeping the previous content anyway.

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

llvm-svn: 224347

[Hexagon] Adding absolute value, and negate with saturation

llvm-svn: 224346

Delete MSVC intermediate files on "make clean" from tests.

lld-link shells out to MSVC for certain types of work, and this
results in some MSVC output files being generated even though
clang / lld are the compiler / linker.  This is expected, so we
make sure to clean these output files on make clean.

llvm-svn: 224345

combine consecutive subvector 16-byte loads into one 32-byte load

This is a fix for PR21709 ( http://llvm.org/bugs/show_bug.cgi?id=21709 ).
When we have 2 consecutive 16-byte loads that are merged into one 32-byte vector,
we can use a single 32-byte load instead.
But we don't do this for SandyBridge / IvyBridge because they have slower 32-byte memops.
We also don't bother using 32-byte *integer* loads on a machine that only has AVX1 (btver2)
because those operands would have to be split in half anyway since there is no support for
32-byte integer math ops.

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

llvm-svn: 224344

[Hexagon] Adding saturate and swizzle instructions.

llvm-svn: 224343

Re-commit the test for regex that I busted last night - now passes under ASAN

llvm-svn: 224342

[AVX512] Add a comment for avx512_broadcast_pat multiclass

llvm-svn: 224341

[Hexagon] Removing old multiply defs and updating references to new versions.

llvm-svn: 224340

The single check for N64 inside MipsDisassemblerBase's subclasses is actually wrong. It should be testing for FeatureGP64bit.There are no functional changes.

llvm-svn: 224339

[mips][microMIPS] Implement SWP and LWP instructions
Differential Revision: http://reviews.llvm.org/D5667

llvm-svn: 224338

Fixing -Wsign-compare warnings; NFC.

llvm-svn: 224337

Add disassembler tests for mips4 platform. There are no functional changes.

llvm-svn: 224335

Masked Load and Store Intrinsics in loop vectorizer.
The loop vectorizer optimizes loops containing conditional memory
accesses by generating masked load and store intrinsics.
This decision is target dependent.

http://reviews.llvm.org/D6527

llvm-svn: 224334

[mips] Fix arguments-struct.ll for Windows and OSX hosts.

llvm-svn: 224333

[ARM] Prevent PerformVCVTCombine from combining a vmul/vcvt with 8 lanes

This would result in a crash since the vcvt used does not support v8i32 types.

llvm-svn: 224332

Fixed 2 typos in help.

llvm-svn: 224331

X86: Added FeatureVectorUAMem for all AVX architectures.
According to AVX specification:

"Most arithmetic and data processing instructions encoded using the VEX prefix and
performing memory accesses have more flexible memory alignment requirements
than instructions that are encoded without the VEX prefix. Specifically,
With the exception of explicitly aligned 16 or 32 byte SIMD load/store instructions,
most VEX-encoded, arithmetic and data processing instructions operate in
a flexible environment regarding memory address alignment, i.e. VEX-encoded
instruction with 32-byte or 16-byte load semantics will support unaligned load
operation by default. Memory arguments for most instructions with VEX prefix
operate normally without causing #GP(0) on any byte-granularity alignment
(unlike Legacy SSE instructions)."

The same for AVX-512.

This change does not affect anything right now, because only the "memop pattern fragment"
depends on FeatureVectorUAMem and it is not used in AVX patterns.
All AVX patterns are based on the "unaligned load" anyway.

llvm-svn: 224330

Renamed RefersToEnclosingLocal bitfield to RefersToCapturedVariable.
Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments.
No functional changes.

llvm-svn: 224329

Remove 'metadata' from comments

llvm-svn: 224328

IR: Stop printing 'metadata' in Metadata::print()

Stop printing `metadata` in `Metadata::print()` and
`Metadata::printAsOperand()`.

llvm-svn: 224327

internal_stat for mips64

llvm-svn: 224326

IR: Make MDNode::dump() useful by adding addresses

It's horrible to inspect `MDNode`s in a debugger.  All of their operands
that are `MDNode`s get dumped as `<badref>`, since we can't assign
metadata slots in the context of a `Metadata::dump()`.  (Why not?  Why
not assign numbers lazily?  Because then each time you called `dump()`,
a given `MDNode` could have a different lazily assigned number.)

Fortunately, the C memory model gives us perfectly good identifiers for
`MDNode`.  Add pointer addresses to the dumps, transforming this:

    (lldb) e N->dump()
    !{i32 662302, i32 26, <badref>, null}

    (lldb) e ((MDNode*)N->getOperand(2))->dump()
    !{i32 4, !"foo"}

into:

    (lldb) e N->dump()
    !{i32 662302, i32 26, <0x100706ee0>, null}

    (lldb) e ((MDNode*)0x100706ee0)->dump()
    !{i32 4, !"foo"}

and this:

    (lldb) e N->dump()
    0x101200248 = !{<badref>, <badref>, <badref>, <badref>, <badref>}

    (lldb) e N->getOperand(0)
    (const llvm::MDOperand) $0 = {
      MD = 0x00000001012004e0
    }
    (lldb) e N->getOperand(1)
    (const llvm::MDOperand) $1 = {
      MD = 0x00000001012004e0
    }
    (lldb) e N->getOperand(2)
    (const llvm::MDOperand) $2 = {
      MD = 0x0000000101200058
    }
    (lldb) e N->getOperand(3)
    (const llvm::MDOperand) $3 = {
      MD = 0x00000001012004e0
    }
    (lldb) e N->getOperand(4)
    (const llvm::MDOperand) $4 = {
      MD = 0x0000000101200058
    }
    (lldb) e ((MDNode*)0x00000001012004e0)->dump()
    !{}

    (lldb) e ((MDNode*)0x0000000101200058)->dump()
    !{null}

into:

    (lldb) e N->dump()
    !{<0x1012004e0>, <0x1012004e0>, <0x101200058>, <0x1012004e0>, <0x101200058>}

    (lldb) e ((MDNode*)0x1012004e0)->dump()
    !{}

    (lldb) e ((MDNode*)0x101200058)->dump()
    !{null}

llvm-svn: 224325

DebugInfo: Update testcase to actually check something

This test was missing a `Debug Info Version` so it's `not grep` was
passing vacuously.  Update it to CHECK for something useful at the same
time so it doesn't bitrot quite so easily in the future.

llvm-svn: 224324

[OPENMP] Bugfix for processing of global variables in OpenMP regions.
Currently, if global variable is marked as a private OpenMP variable, the compiler crashes in debug version or generates incorrect code in release version. It happens because in the OpenMP region the original global variable is used instead of the generated private copy. It happens because currently globals variables are not captured in the OpenMP region.
This patch adds capturing of global variables iff private copy of the global variable must be used in the OpenMP region.
Differential Revision: http://reviews.llvm.org/D6259

llvm-svn: 224323

Sema: Don't crash converting to bool from _Atomic

Turning our _Atomic L-value into an R-value removes its _Atomic-ness.
However, we didn't update our 'FromType' which made
ScalarTypeToBooleanCastKind think we were trying to pass it a
non-scalar.

This fixes PR21836.

llvm-svn: 224322

Temporarily disable CompactUnwindInfo::GetCompactUnwindInfoForFunction.
The compact unwind importer is getting the wrong unwind info for one
case that I found.  I haven't been able to fix the problem tonight
and I don't want to leave TOT behaving incorrectly, so just ignore
compact unwind until I can get to the bottom of this.

llvm-svn: 224321

Improve handling of value dependent expressions in __attribute__((enable_if)), both in the condition expression and at the call site. Fixes PR20988!

llvm-svn: 224320

ARM: diagnose deprecated syntax

The use of SP and PC in the register list for stores is deprecated on ARM
(ARM ARM A.8.8.199):

  ARM deprecates the use of ARM instructions that include the SP or the PC in
  the list.

Provide a deprecation warning from the assembler in the case that the syntax is
ever seen.

llvm-svn: 224319

[PowerPC] Improve instruction selection bit-permuting operations (32-bit)

The PowerPC backend, somewhat embarrassingly, did not generate an
optimal-length sequence of instructions for a 32-bit bswap. While adding a
pattern for the bswap intrinsic to fix this would not have been terribly
difficult, doing so would not have addressed the real problem: we had been
generating poor code for many bit-permuting operations (by which I mean things
like byte-swap that permute the bits of one or more inputs around in various
ways). Here are some initial steps toward solving this deficiency.

Bit-permuting operations are represented, at the SDAG level, using ISD::ROTL,
SHL, SRL, AND and OR (mostly with constant second operands). Looking back
through these operations, we can build up a description of the bits in the
resulting value in terms of bits of one or more input values (and constant
zeros). For each bit, we compute the rotation amount from the original value,
and then group consecutive (value, rotation factor) bits into groups. Groups
sharing these attributes are then collected and sorted, and we can then
instruction select the entire permutation using a combination of masked
rotations (rlwinm), imm ands (andi/andis), and masked rotation inserts
(rlwimi).

The result is that instead of lowering an i32 bswap as:

rlwinm 5, 3, 24, 16, 23
rlwinm 4, 3, 24, 0, 7
rlwimi 4, 3, 8, 8, 15
rlwimi 5, 3, 8, 24, 31
rlwimi 4, 5, 0, 16, 31

we now produce:

rlwinm 4, 3, 8, 0, 31
rlwimi 4, 3, 24, 16, 23
rlwimi 4, 3, 24, 0, 7

and for the 'test6' example in the PowerPC/README.txt file:

 unsigned test6(unsigned x) {
   return ((x & 0x00FF0000) >> 16) | ((x & 0x000000FF) << 16);
 }

we used to produce:

lis 4, 255
rlwinm 3, 3, 16, 0, 31
ori 4, 4, 255
and 3, 3, 4

and now we produce:

rlwinm 4, 3, 16, 24, 31
rlwimi 4, 3, 16, 8, 15

and, as a nice bonus, this fixes the FIXME in
test/CodeGen/PowerPC/rlwimi-and.ll.

This commit does not include instruction-selection for i64 operations, those
will come later.

llvm-svn: 224318

Revert "Fix installheaders target's permissions"

The install of headers excludes the support directory, so these chmod
calls fail on non-existent directories, as seen on this bot:

http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/2801/console

This reverts commit r224300.

llvm-svn: 224317

AST: Fix the linkage of static vars in fn template specializations

We that static variables in function template specializations were
externally visible.  The manglers assumed that externally visible static
variables were numbered in Sema.  We would end up mangling static
variables in the same specialization with the same mangling number which
would give all of them the same name.

This fixes PR21904.

llvm-svn: 224316

Add an MACOS_VERSION_UNKNOWN_NEWER enum value for OS X versions above 10.10.

We recently had a broken version check because an newer OS X version is treated as MACOS_VERSION_UNKNOWN which is less than all the defined values. Let's have a separate enum value for unknown but newer versions, so the ">=" and "<=" version checks still work even in upcoming OS X releases.

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

llvm-svn: 224315

ARM: 80-column

clang-format a function with an overly long string constant.  NFC.

llvm-svn: 224314

LiveRangeCalc: Rewrite subrange calculation

This changes subrange calculation to calculate subranges sequentially
instead of in parallel. The code is easier to understand that way and
addresses the code review issues raised about LiveOutData being
hard to understand/needing more comments by removing them :)

llvm-svn: 224313

Remove the last unnecessary member variable of mapped_file_region. NFC.

llvm-svn: 224312

Convert a member variable to a local variable. NFC.

llvm-svn: 224311

Instead of rolling our own, use the C++11 sanctioned solution

llvm-svn: 224310

Remove unused member and simplify. NFC.

llvm-svn: 224309

Fix data symbolization with libbacktrace. Patch by Jakub Jelinek!

llvm-svn: 224308

Start adding thin archive support.

This is just sufficient for 'ar t' to work.

llvm-svn: 224307

If a binary was stripped we sometimes didn't show the ivars of an Objective C class correctly. Now we do as we consult the runtime data for the class so we don't have to have a symbol in the symbol table.

Fixed:
1 - try the symbol table symbol for an ObjC ivar and use it if available
2 - fall back to using the runtime data since it is slower to gather via memory read
3 - Fixed our hidden ivars test case to test this to ensure we don't regress
4 - split out a test case in the hidden ivars to cover only the part that was failing so we don't have an expected failure for all of the other content in the test.

<rdar://problem/18882687>

llvm-svn: 224306

[ASan] Allow to atomically modify malloc_context_size at runtime.

Summary:
Introduce __asan::malloc_context_size atomic that is used to determine
required malloc/free stack trace size. It is initialized with
common_flags()->malloc_context_size flag, but can later be overwritten
at runtime (e.g. when ASan is activated / deactivated).

Test Plan: regression test suite

Reviewers: kcc, eugenis

Subscribers: llvm-commits

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

llvm-svn: 224305

Appease the c++14 buildbots

llvm-svn: 224304

Clarify the code in checkDLLAttribute()

Update the comments to make it more clear what's going on, and address
Richard's comments from PR21718. This doesn't fix that bug, but hopefully
makes the code easier to understand.

llvm-svn: 224303

Fix a bug in llvm-objdump’s -private-headers for 32-bit Mach-O files
printing the section header.  And add some tests for this for 32-bit files.

llvm-svn: 224302

Comment out the breaking tests until I figure out what's going on here.

llvm-svn: 224301

Fix installheaders target's permissions

llvm-svn: 224300