llvm-svn: 227573

Committed unreviewed with permission.

llvm-svn: 227572

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

llvm-svn: 227571

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

llvm-svn: 227570

llvm-svn: 227569

[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

We don't really care about enabling RTTI with -fexceptions, only with
-fcxx-exceptions.

llvm-svn: 227567

Bug found with afl-fuzz

llvm-svn: 227566

In OpenCL 1.2, using double no longer requires using the pragma cl_khr_fp64,
instead a kernel is allowed to use double, but must first have queried
clGetDeviceInfo's CL_DEVICE_DOUBLE_FP_CONFIG.

Page 197, section 6.1.1 of the OpenCL 1.2 specification has a footnote 23
describing this behaviour.

I've also added test cases such that the pragma must be used if targeting
OpenCL 1.0 or 1.1, but is ignored in 1.2 and 2.0.

Patch by Neil Henning!

Reviewers: Pekka Jääskeläinen

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

llvm-svn: 227565

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

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

llvm-svn: 227560

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

llvm-svn: 227559

llvm-svn: 227558

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

Fatal errors disable all further diagnostics.  Continuing to permit
template instantiation does nothing but make it take longer for clang to
finish with the TU.

Instead, halt all further instantiation.

Fixed in PR22396.

llvm-svn: 227556

llvm-svn: 227555

llvm-svn: 227554

llvm-svn: 227553

for; match files starting with "mach", not "mach." so
the old common name mach_kernel will still be matched.

llvm-svn: 227552

We have a DEBUG_TYPE macro for the same debug string already
at the beginning of the file.

llvm-svn: 227551

[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

SimpleFileWrapper was a class to wrap an existing (possibly non-mutable)
file as a mutable file. We used instances of the class in RoundTrip*
passes, because the passes convert mutable files to non-mutable files,
and we needed to convert them back to mutable.

That feature can be implemented without defining a new class. Generally
speaking, if we can implement a feature without defining a class and
using only public interface of exsiting classes, that's preferred way
to do that. And this is the case.

llvm-svn: 227549

llvm-svn: 227548

llvm-svn: 227547

llvm-svn: 227546

to match LLVM's preferred style.

llvm-svn: 227545

so we need to move the dbg.declare intrinsics that describe them, too.

llvm-svn: 227544

Now it is clear that std::move() is meaningless here.

llvm-svn: 227543

for the target dependent one.

llvm-svn: 227542

upon as an argument and store/use that in the entire function.

llvm-svn: 227541

llvm-svn: 227540

llvm-svn: 227539

version. Update NVPTXInstrInfo accordingly.

llvm-svn: 227538

llvm-svn: 227536

accordingly.

llvm-svn: 227535

llvm-svn: 227534

accumulateAndSortLibcalls in LTOCodeGenerator.cpp collects names of runtime
library functions which are used to identify user-defined functions that should
be protected. Previously, this function would only scan the TargetLowering
object belonging to the "main" subtarget for the library function names. This
commit changes it to scan all per-function subtargets.

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

llvm-svn: 227533