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

Sema: Check value dependent casts when possible

We know that const_cast<char *>((void)Something) is ill-formed, even if
'Something' is dependent because you can't cast from void to a pointer
type.

This fixes PR21845.

llvm-svn: 224299

Once more w/o the typo.

llvm-svn: 224298

Fix the literal string that I said would be six elements long to actually be six elements long. Octal. Sheesh.

llvm-svn: 224297

Add test to ensure that iterator_traits<NotAnIterator> doesn't have a value type

llvm-svn: 224295

ARM/AArch64: Attach the FrameSetup MIFlag to CFI instructions.
Debug info marks the first instruction without the FrameSetup flag
as being the end of the function prologue. Any CFI instructions in the
middle of the function prologue would cause debug info to end the prologue
too early and worse, attach the line number of the CFI instruction, which
incidentally is often 0.

llvm-svn: 224294

[Hexagon] Adding doubleword multiplies with and without accumulation.

llvm-svn: 224293

Implement LWG 2217 - operator==(sub_match, string) slices on embedded '\0's

llvm-svn: 224292

Sink the isa into the assert

llvm-svn: 224291

Now that AddressOf() does sane things with const results, this check is wrong. Since this is actually quite orthogonal to what this test is all about, actually get rid of the assertions

llvm-svn: 224290

[Hexagon] Adding halfword to doubleword multiplies.

llvm-svn: 224289

[Hexagon] Adding logical-logical accumulation instructions and tests.

llvm-svn: 224288

Diagnose function template definitions inside functions

The parser can only be tricked into parsing a function template
definition by inserting a typename keyword before the function template
declaration. This used to make us crash, and now it's fixed.

While here, remove an unneeded boolean parameter from ParseDeclGroup.
This boolean always corresponded to non-typedef declarators at file
scope. ParseDeclGroup already has precise diagnostics for the function
definition typedef case, so we can let that through.

Fixes PR21839.

llvm-svn: 224287

[asan] introduce __sanitizer_set_death_callback, deprecate __asan_set_death_callback

llvm-svn: 224286

Teach ScalarEvolution to exploit min and max expressions when proving
isKnownPredicate.

The motivation for this change is to optimize away checks in loops
like this:

    limit = min(t, len)
    for (i = 0 to limit)
      if (i >= len || i < 0) throw_array_of_of_bounds();
      a[i] = ...

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

llvm-svn: 224285

Added missing tests for X86vzmovl folding. NFC.

llvm-svn: 224284

x86: Emit LOCK prefix after DATA16

Summary: x86 allows either ordering for the LOCK and DATA16 prefixes, but using GCC+GAS leads to different code generation than using LLVM. This change matches the order that GAS emits the x86 prefixes when a semicolon isn't used in inline assembly (see tc-i386.c comment before define LOCK_PREFIX), and helps simplify tooling that operates on the instruction's byte sequence (such as NaCl's validator). This change shouldn't have any performance impact.

Test Plan: ninja check

Reviewers: craig.topper, jvoung

Subscribers: jfb, llvm-commits

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

llvm-svn: 224283

[Hexagon] Adding a number of additional multiply forms with tests.

llvm-svn: 224282

Clean up warning about unused variable

llvm-svn: 224281

Hand-modify a testcase (still PR21532)

Bot was still tripping [1] on a testcase the upgrade script didn't
handle in 224269.  This is still fallout from r224257.

[1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25435

llvm-svn: 224280

Silene -Wreorder warning.

llvm-svn: 224279

Revert "LiveRangeCalc: Rewrite subrange calculation"

Revert until I find out why non-subreg enabled targets break.

This reverts commit 6097277eefb9c5fb35a7f493c783ee1fd1b9d6a7.

llvm-svn: 224278

Revert of r223763, in spirit.

r223763 was made to work around a temporary issue where a user of the
JIT was passing down a declaration (incorrectly). This shouldn't
occur, so assert rather than silently continue.

llvm-svn: 224277

Update lib/profile tests for metadata assembly change

Running the upgrade script from PR21532.  Hopefully this will unstick
compiler-rt bots [1] after r224257.

[1]: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/181/

llvm-svn: 224276

Provide a SBFrame.register/.reg helper on the Python side of SBFrame to vend a flattened view of registers

Our actual view of registers is a set of register sets, each one of which contains a subset of the actual registers
This makes trivial scripting operations tedious ("I just want to read r7!")

This helper allows things like: print lldb.frame.reg["r7"]

Fixes rdar://19185662

llvm-svn: 224275

Clarify HowFarToZero computation when the step is a positive power of two.  Functionally this should be identical to the existing code except for the case where Step is maximally negative (eg, INT_MIN).  We now punt in that one corner case to make reasoning about the code easier.

llvm-svn: 224274

[Hexagon] Adding misc multiply encodings and tests.

llvm-svn: 224273

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: 224272

Handle errors in lambda prototype instantiation correctly

Previously we would attempt to build a TypeSourceInfo for a null type,
and then we would forget to pop the function scope before returning an
error.

Reviewers: rsmith

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

llvm-svn: 224271

profile: Add the relevant parts of lib/profile to cc_kext on darwin

Patch by Lawrence D'Anna. Thanks!

llvm-svn: 224270

Run upgrade script from PR21532 to match LLVM changes

Update tests for LLVM assembly format change in r224257 using the script
attached to PR21532.  I'm hoping this unsticks the bot [1].

[1]: http://lab.llvm.org:8011/builders/polly-amd64-linux/builds/25432

llvm-svn: 224269

Sema: Cleanup and improve string-plus-char checking.

Patch by Anders Rönnholm

llvm-svn: 224268

[Hexagon] Adding doubleworld accumulating multiplies of halfwords.

llvm-svn: 224267

[Hexagon] Adding accumulating half word multiplies.

llvm-svn: 224266

[Hexagon] Adding multiply with rnd/sat/rndsat

llvm-svn: 224265

[X86] And also test INSERTPS shuffle mask pretty-printing.

For r224260.

llvm-svn: 224264

LiveRangeCalc: use more range based for loops; NFC

llvm-svn: 224263

Update this testcase for the new metadata assembler syntax.

llvm-svn: 224262

[Hexagon] Adding encoding bits for halfword multiplies.

llvm-svn: 224261

[X86] Also pretty-print shuffle mask for INSERTPS rm variants.

llvm-svn: 224260

IR: Make metadata typeless in assembly, clang side

Match LLVM changes from r224257.

llvm-svn: 224259

Replace ioctl with select to reduce processor usage by lldb-mi on OSX.
This saga started with a hang on OSX. 2 solutions were proposed.
1) 'select' based solution works ok on OSX but slows down test completion time
on Linux many times.
2) 'ioctl' base solution also works but it causes heavy processor usage on OSX
as reported by Ilia K.

But as the original hang did not occur on Linux so this commit re-introduces the
'select' in conditional code so that it only runs for OSX. There is no need for
this 'fix' to run on Linux.

Initial patch by Ilia K <ki.stfu@gmail.com>. A few changes were made by me.

llvm-svn: 224258

IR: Make metadata typeless in assembly

Now that `Metadata` is typeless, reflect that in the assembly.  These
are the matching assembly changes for the metadata/value split in
r223802.

  - Only use the `metadata` type when referencing metadata from a call
    intrinsic -- i.e., only when it's used as a `Value`.

  - Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`
    when referencing it from call intrinsics.

So, assembly like this:

    define @foo(i32 %v) {
      call void @llvm.foo(metadata !{i32 %v}, metadata !0)
      call void @llvm.foo(metadata !{i32 7}, metadata !0)
      call void @llvm.foo(metadata !1, metadata !0)
      call void @llvm.foo(metadata !3, metadata !0)
      call void @llvm.foo(metadata !{metadata !3}, metadata !0)
      ret void, !bar !2
    }
    !0 = metadata !{metadata !2}
    !1 = metadata !{i32* @global}
    !2 = metadata !{metadata !3}
    !3 = metadata !{}

turns into this:

    define @foo(i32 %v) {
      call void @llvm.foo(metadata i32 %v, metadata !0)
      call void @llvm.foo(metadata i32 7, metadata !0)
      call void @llvm.foo(metadata i32* @global, metadata !0)
      call void @llvm.foo(metadata !3, metadata !0)
      call void @llvm.foo(metadata !{!3}, metadata !0)
      ret void, !bar !2
    }
    !0 = !{!2}
    !1 = !{i32* @global}
    !2 = !{!3}
    !3 = !{}

I wrote an upgrade script that handled almost all of the tests in llvm
and many of the tests in cfe (even handling many `CHECK` lines).  I've
attached it (or will attach it in a moment if you're speedy) to PR21532
to help everyone update their out-of-tree testcases.

This is part of PR21532.

llvm-svn: 224257

Warn when attribute 'optnone' conflicts with attributes on a
different declaration of the same function.

llvm-svn: 224256