llvm-svn: 227619

This fixes a crash in Unigine Heaven.

llvm-svn: 227618

Some tests have tabs, some don't.
In vector-[sz]ext.ll, space wins (well duh!).

llvm-svn: 227615

llvm-svn: 227614

llvm-svn: 227613

llvm-svn: 227612

MSDN's x64 software conventions page says that this is one of the fixed
list of legal epilogues:
https://msdn.microsoft.com/en-us/library/tawsa7cb.aspx

Presumably this is how the unwinder distinguishes epilogue jumps from
in-function control flow.

Also normalize the way we place "## TAILCALL" comments on such jumps.

llvm-svn: 227611

llvm-svn: 227609

since r199487.

llvm-svn: 227608

llvm-svn: 227607

Add tie breaker to colorChainSet() sort so that processing order doesn't
depend on std::set order, which depends on pointer order, which is
unstable from run to run.

No test case as this is nearly impossible to reproduce.

Phabricator Review: http://reviews.llvm.org/D7265
Patch by Geoff Berry <gberry@codeaurora.org>!

llvm-svn: 227606

llvm-svn: 227605

instruction and generalize it to optionally dereference the variable.
Follow-up to r227544.

llvm-svn: 227604

If the original FPU specification involved a restricted VFP unit (d16), ensure
that we reset the functionality when we encounter a new FPU type.  In
particular, if the user specified vfpv3-d16, but switched to a VFPv3 (which has
32 double precision registers), we would fail to reset the D16 feature, and
treat it as being equivalent to vfpv3-d16.

llvm-svn: 227603

This reverts commit r227489, since this is the real one failing the bots.

llvm-svn: 227602

Revert "Revert "Matching ARM change for r227481: DebugInfo: Teach Fast ISel to respect the debug location of comparisons in jumps.""

This reverts commit r227600, since that reverted the wrong comit. Sorry.

llvm-svn: 227601

Revert "Matching ARM change for r227481: DebugInfo: Teach Fast ISel to respect the debug location of comparisons in jumps."

This reverts commit r227488 as it was failing ARM bots.

llvm-svn: 227600

llvm-svn: 227599

llvm-svn: 227598

In the case of an invalid FPU name, place the caret at the name rather than FPU
directive.

llvm-svn: 227595

llvm-svn: 227594

Added a test case for it.
Also added run lines for the test case in r227566.

Bugs found with afl-fuzz

llvm-svn: 227589

llvm-svn: 227588

I thought it was enough to just not add the tool subdirectory,
but apparently I need to explicitly mark it ignore.

llvm-svn: 227587

In preparation for adding PDB support to LLVM, this moves the
DWARF parsing code to its own subdirectory under DebugInfo, and
renames LLVMDebugInfo to LLVMDebugInfoDWARF.

This is purely a mechanical / build system change.

Differential Revision: http://reviews.llvm.org/D7269
Reviewed by: Eric Christopher

llvm-svn: 227586

The FPU directive permits the user to switch the target FPU, enabling
instructions that would be otherwise unavailable.  However, when configuring the
new subtarget features, we would not enable the implied functions for newer
FPUs.  This would result in invalid rejection of valid input.  Ensure that we
inherit the implied FPU functionality when enabling newer versions of the FPU.
Fortunately, these are mostly hierarchical, unlike the CPUs.

Addresses PR22395.

llvm-svn: 227584

llvm-svn: 227582

analyses back into the LTO code generator.

The pass manager builder (and the transforms library in general)
shouldn't be referencing the target machine at all.

This makes the LTO population work like the others -- the data layout
and target transform info need to be pre-populated.

llvm-svn: 227576

covering switch.

llvm-svn: 227575

llvm-svn: 227574

llvm-svn: 227573

[mips] Manually replace JAL pseudo-instructions with their JALR equivalent, instead of using InstAlias.

Summary:
This is needed by the .cprestore assembler directive.

This directive needs to be able to insert an LW instruction after every JALR replacement of a JAL pseudo-instruction
(and never after a JALR which has NOT been a result of a pseudo-instruction replacement).

The problem with using InstAlias for these is that after it replaces the pseudo-instruction, we can't find out if the resulting JALR instruction
was generated by an InstAlias or not, so we don't know whether or not to insert our LW instruction.

By replacing it manually, we know when the pseudo-instruction replacement happens and we can insert the LW instruction correctly.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: emaste, llvm-commits

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

llvm-svn: 227568

Bug found with afl-fuzz

llvm-svn: 227566

llvm-svn: 227564

llvm-svn: 227563

Change a very hot piece of code in TableGen's register unit computations to use bit vectors rather than arrays.

For target descriptions with very large and very dense register files, TableGen
can take an extremely long time to run.  This change makes a dent in that (~15%
in my measurements) by accelerating the single hottest operation with better data
structures.

I believe there's still a lot of room to make this even faster with more global
changes that require replacing some of the existing datastructures in this area
with bit vectors, but that's a more involved change and I wanted to get this
simpler improvement in first.

llvm-svn: 227562

Move the target specific test case arbitrary-induction-step.ll to test/Transforms/LoopVectorize/AArch64 folder.

llvm-svn: 227561

Previously, only -1 and +1 step values are supported for induction variables. This patch extends LV to support
arbitrary constant steps.
Initial patch by Alexey Volkov. Some bug fixes are added in the following version.

Differential Revision: http://reviews.llvm.org/D6051 and http://reviews.llvm.org/D7193

llvm-svn: 227557

[AArch64]Fix PR21675, a bug about lowering llvm.ctpop.i32. We should noot use "DAG.getUNDEF(MVT::v8i8)" to get all zero vector.
Patch by Wei-cheng Wang.

llvm-svn: 227550

llvm-svn: 227548