All supported platforms have half-way decent C99 support.

llvm-svn: 231679

llvm-svn: 231678

In the case where just tables are part of the function section, this produces
more readable assembly by avoiding switching to the eh section and back
to .text.

This would also break with non unique section names, as trying to switch to
a unique section actually creates a new one.

llvm-svn: 231677

llvm-svn: 231676

These are pure virtual in the base class, so the compiler checks that they
are implemented.

llvm-svn: 231673

Summary:
Code is mostly copied from AArch64 port and modified where needed for Mips.

This handles the "non" legal cases of logical ops. Legal cases are handled by tablegen patterns.

Test Plan:
Make check test logopm.ll

All of test-suite passes at O0/O2 and mips32 r1/r2 with this new change.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: echristo, llvm-commits, aemerson, rfuhler

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

llvm-svn: 231665

Found by -Wmissing-prototypes. NFC.

llvm-svn: 231664

llvm-svn: 231663

llvm-svn: 231662

NFC.

llvm-svn: 231661

NFC.

llvm-svn: 231660

This is a candidate for stable.

llvm-svn: 231659

llvm-svn: 231658

Also, replaced line with 'target triple' with flag -mtriple on the RUN line.
Removed the data layout string as it is not needed.

llvm-svn: 231654

As it broke llvm bootstrap.

llvm-svn: 231635

Fix a bug in the LLParser where we failed to diagnose landingpads with non-constant clause operands.

Fixing this also exposed a related issue where the landingpad under construction was not
cleaned up when an error was raised, which would cause bad reference errors before the
error could actually be printed.

llvm-svn: 231634

For inner one of nested loops, it is more likely to be a hot loop,
and the runtime check can be promoted out from patch 0001, so the
overhead is less, we can try a doubled threshold to unroll more loops.

llvm-svn: 231632

Runtime unrolling is an expensive optimization which can bring benefit
only if the loop is hot and iteration number is relatively large enough.
For some loops, we know they are not worth to be runtime unrolled.
The scalar loop from vectorization is one of the cases.

llvm-svn: 231631

Runtime unrollng will introduce a runtime check in loop prologue.
If the unrolled loop is a inner loop, then the proglogue will be inside
the outer loop. LICM pass can help to promote the runtime check out if
the checked value is loop invariant.

llvm-svn: 231630

Summary:
See the two test cases.

; Can fold fcmp with undef on one side by choosing NaN for the undef

; Can fold fcmp with undef on both side
;   fcmp u_pred undef, undef -> true
;   fcmp o_pred undef, undef -> false
; because whatever you choose for the first undef
; you can choose NaN for the other undef

Reviewers: hfinkel, chandlerc, majnemer

Reviewed By: majnemer

Subscribers: majnemer, llvm-commits

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

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231626

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231624

Patch by Richard (legalize at xmission dot com).

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

llvm-svn: 231617

Teach DataLayout to infer a plausible alignment for things even when nothing is specified by the user.

llvm-svn: 231613

There were cases where the backend computed a wrong permute mask for a VPERM2X128 node.

Example:
\code
define <8 x float> @foo(<8 x float> %a, <8 x float> %b) {
  %shuffle = shufflevector <8 x float> %a, <8 x float> %b, <8 x i32> <i32 undef, i32 undef, i32 6, i32 7, i32 undef, i32 undef, i32 6, i32 7>
  ret <8 x float> %shuffle
}
\code end

Before this patch, llc (with -mattr=+avx) emitted the following vperm2f128:
  vperm2f128 $0, %ymm0, %ymm0, %ymm0  # ymm0 = ymm0[0,1,0,1]

With this patch, llc emits a vperm2f128 with a correct permute mask:
  vperm2f128 $17, %ymm0, %ymm0, %ymm0  # ymm0 = ymm0[2,3,2,3]

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

llvm-svn: 231601

Or fold them into a initializer list which has the same effect. NFC.

llvm-svn: 231598

We have an increasing number of cases where we are creating commuted shuffle masks - all implementing nearly the same code.

This patch adds a static helper function - ShuffleVectorSDNode::commuteMask() and replaces a number of cases to use it.

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

llvm-svn: 231581

lib/ExecutionEngine/Targets has no Makefile, causing the autoconf build
to fail.  Solve this by bringing the COFF implementation of RuntimeDyld
in line like the Mach-O and ELF implementations.

llvm-svn: 231579

NFC.

llvm-svn: 231577

llvm-svn: 231576

Provide basic support for dynamically loadable coff objects. Only handles a subset of x64 currently.

Patch by Andy Ayers!

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

llvm-svn: 231574

In theory this allows the compiler to skip materializing the array on
the stack. In practice clang often fails to do that, but that's a
different story. NFC.

llvm-svn: 231571

llvm-svn: 231569

llvm-svn: 231567

llvm-svn: 231566

llvm-svn: 231565

This patch fixes the logic in the DAGCombiner that folds an AND node according
to rule: (and (X (load V)), C) -> (X (load V))

An AND between a vector load 'X' and a constant build_vector 'C' can be folded
into the load itself only if we can prove that the AND operation is redundant.
The algorithm implemented by 'visitAND' firstly computes the splat value 'S'
from C, and then checks if S has the lower 'B' bits set (where B is the size in
bits of the vector element type). The algorithm takes into account also the
'undef' bits in the splat mask.

Unfortunately, the algorithm only worked under the assumption that the size of S
is a multiple of the vector element type. With this patch, we conservatively
avoid folding the AND if the splat bits are not compatible with the vector
element type.

Added X86 test and-load-fold.ll

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

llvm-svn: 231563

build this header in a module.

llvm-svn: 231561

libc++. This lets me almost self-host on Linux with libc++ and libc++abi
very simply.

Currently, MCJIT and OrcJIT are failing due to uncaught exceptions, and
the Go binding tests are failing to build due to not linking in the
correct C++ standard library.

llvm-svn: 231560

generation.

llvm-svn: 231558

This will provide the analogous replacements for the PassManagerBuilder
and other code long term. This code is extracted from the opt tool
currently, and I plan to extend it as I build up support for using the
new pass manager in Clang and other places.

Mailing this out for review in part to let folks comment on the terrible names
here. A brief word about why I chose the names I did.

The library is called "Passes" to try and make it clear that it is a high-level
utility and where *all* of the passes come together and are registered in
a common library. I didn't want it to be *limited* to a registry though, the
registry is just one component.

The class is a "PassBuilder" but this name I'm less happy with. It doesn't
build passes in any traditional sense and isn't a Builder-style API at all. The
class is a PassRegisterer or PassAdder, but neither of those really make a lot
of sense. This class is responsible for constructing passes for registry in an
analysis manager or for population of a pass pipeline. If anyone has a better
name, I would love to hear it. The other candidate I looked at was
PassRegistrar, but that doesn't really fit either. There is no register of all
the passes in use, and so I think continuing the "registry" analog outside of
the registry of pass *names* and *types* is a mistake. The objects themselves
are just objects with the new pass manager.

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

llvm-svn: 231556