Patch by Asiri Rathnayake.

llvm-svn: 209656

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

llvm-svn: 209655

llvm-svn: 209654

This way does not require a __sanitizer_cov_dump() call. That's
important on Android, where apps can be killed at arbitrary time.

We write raw PCs to disk instead of module offsets; we also write
memory layout to a separate file. This increases dump size by the
factor of 2 on 64-bit systems.

llvm-svn: 209653

llvm-svn: 209652

A test in test/Generic creates a DAG where the NZCV output of an ADCS is used
by multiple nodes. This makes LLVM want to save a copy of NZCV for later, which
it couldn't do before.

This should be the last fix required for the aarch64 buildbot.

llvm-svn: 209651

Cortex-M4 only has single-precision floating point support, so any LLVM
"double" type will have been split into 2 i32s by now. Fortunately, the
consecutive-register framework turns out to be precisely what's needed to
reconstruct the double and follow AAPCS-VFP correctly!

rdar://problem/17012966

llvm-svn: 209650

llvm-svn: 209649

llvm-svn: 209648

llvm-svn: 209647

These are tested by test/CodeGen/Generic, so we should probably know
how to deal with them. Fortunately generic code does it if asked.

llvm-svn: 209646

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

llvm-svn: 209645

llvm-svn: 209644

Summary:
Implemented an InstCombine transformation that takes a blendv* intrinsic
call and translates it into an IR select, if the mask is constant.

This will eventually get lowered into blends with immediates if possible,
or pblendvb (with an option to further optimize if we can transform the
pblendvb into a blend+immediate instruction, depending on the selector).
It will also enable optimizations by the IR passes, which give up on
sight of the intrinsic.

Both the transformation and the lowering of its result to asm got shiny
new tests.

The transformation is a bit convoluted because of blendvp[sd]'s
definition:

Its mask is a floating point value! This forces us to convert it and get
the highest bit. I suppose this happened because the mask has type
__m128 in Intel's intrinsic and v4sf (for blendps) in gcc's builtin.

I will send an email to llvm-dev to discuss if we want to change this or
not.

Reviewers: grosbach, delena, nadav

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

llvm-svn: 209643

llvm-svn: 209642

Patch by Gideon Billings.

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

llvm-svn: 209641

llvm-svn: 209640

No functionality change.

llvm-svn: 209639

This seems to match what gcc does for ppc and what every other llvm
backend does.

llvm-svn: 209638

This commit is debatable. There are two possible approaches, neither
of which is really satisfactory:

1. Use "@foo(i1 zeroext)" to mean an extension to 32-bits on Darwin,
   and 8 bits otherwise.
2. Redefine "@foo(i1)" to mean that the i1 is extended by the caller
   to 8 bits. This goes against the spirit of "zeroext" I think, but
   it's a bit of a vague construct anyway (by definition you're going
   to extend to the amount required by the ABI, that's why it's the
   ABI!).

This implements option 2. The DAG machinery really isn't setup for the
first (there's a fairly strong assumption that "zeroext" goes to at
least the smallest register size), and even if it was the resulting
DAG looks like it would be inferior in many cases.

Theoretically we could add AssertZext nodes in the consumers of
ABI-passed values too now, but this actually seems to make the code
worse in practice by making truncation proceed in two steps. The code
produced is equally valid if we continue to assume only the low bit is
defined.

Should fix PR19850

llvm-svn: 209637

We can eliminate the custom C++ code in favour of some TableGen to
check the same things. Functionality should be identical, except for a
buffer overrun that was present in the C++ code and meant webkit
failed if any small argument needed to be passed on the stack.

llvm-svn: 209636

Rejecting the mutable specifier on a freestanding type declaration, instead of supporting it as a "extension" (which serves no purpose). Un-XFAILing the test for mutable specifiers.

llvm-svn: 209635

llvm-svn: 209634

llvm-svn: 209633

The header is for POSIX streams functionality, and does not exist on
FreeBSD, OS X, or contemporary Linux distributions.

llvm-svn: 209632

We should later rename this file (probably MIUtilSystemPOSIX), but
more clean-up is still needed here, and we can wait until we better
understand how this code may be shared between FreeBSD, Linux, and OS X.

llvm-svn: 209631

Presumably included by header leakage on other platforms.

llvm-svn: 209630

llvm-svn: 209629

llvm-svn: 209628

Add tests for the following transform:

 str X, [x0, #32]
  ...
 add x0, x0, #32
  ->
 str X, [x0, #32]!

with X being either w1, x1, s0, d0 or q0.

llvm-svn: 209627

No functional changes intended.

llvm-svn: 209626

llvm-svn: 209625

Cover the following cases:

  ldr X, [x0, #32]
   ...
  add x0, x0, #32
   ->
  ldr X, [x0, #32]!

with X being either w1, x1, s0, d0 or q0.

llvm-svn: 209624

llvm-svn: 209623

[ASan/Win tests] Remove the extra 'cat' in front of FileCheck now that it's clear we should use GnuWin32 rather than Cygwin on the PATH on Windows (see PR19744)

llvm-svn: 209622

llvm-svn: 209621

llvm-svn: 209620

llvm-svn: 209619

We have a couple of regression tests for load/store pairing, but (to my knowledge) there are no regression tests for the load/store + add/sub folding.

As a first step towards increased test coverage of this area, this commit adds a test for one instance of a load + add to pre-indexed load transformation.

llvm-svn: 209618

and via the command line, mirroring similar functionality in LoopUnroll.  In
situations where clients used custom unrolling thresholds, their intent could
previously be foiled by LoopRotate having a hardcoded threshold.

llvm-svn: 209617