[PPC64LE] Temporarily disable VSX support in little-endian mode

This is a preliminary patch for the PowerPC64LE support.  In stage 1
of the vector support, we will support the VMX (Altivec) instruction
set, but will not yet support the VSX instructions.  This is merely a
staging issue to provide functional vector support as soon as
possible.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210271 91177308-0d34-0410-b5e6-96231b3b80d8
Document how to select build configuration with Visual C++ IDE or command line.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210273 91177308-0d34-0410-b5e6-96231b3b80d8
Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute.
It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables.

This also adds backend support for generating the jump-instruction tables on ARM and X86.
Note that since the jumptable attribute creates a second function pointer for a
function, any function marked with jumptable must also be marked with unnamed_addr.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210280 91177308-0d34-0410-b5e6-96231b3b80d8
Removing spurious dependency of IPO on JumpInstrTables


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210281 91177308-0d34-0410-b5e6-96231b3b80d8
[PPC64LE] Correct vperm -> shuffle transform for little endian

As discussed in cfe commit r210279, the correct little-endian
semantics for the vec_perm Altivec interfaces are implemented by
reversing the order of the input vectors and complementing the permute
control vector.  This converts the desired permute from little endian
element order into the big endian element order that the underlying
PowerPC vperm instruction uses.  This is represented with a
ppc_altivec_vperm intrinsic function.

The instruction combining pass contains code to convert a
ppc_altivec_vperm intrinsic into a vector shuffle operation when the
intrinsic has a permute control vector (mask) that is a constant.
However, the vector shuffle operation assumes that vector elements are
in natural order for their endianness, so for little endian code we
will get the wrong result with the existing transformation.

This patch reverses the semantic change to vec_perm that was performed
in altivec.h by once again swapping the input operands and
complementing the permute control vector, returning the element
ordering to little endian.

The correctness of this code is tested by the new perm.c test added in
a previous patch, and by other tests in the test suite that fail
without this patch.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210282 91177308-0d34-0410-b5e6-96231b3b80d8
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output.

This is a first step in seeing if it is possible to make llvm-nm produce
the same output as darwin's nm(1).  Darwin's default format is bsd but its
-m output prints the longer Mach-O specific details.  For now I added the
"-format darwin" to do this (whos name may need to change in the future).
As there are other Mach-O specific flags to nm(1) which I'm hoping to add some
how in the future.  But I wanted to see if I could get the correct output for
-m flag using llvm-nm and the libObject interfaces.

I got this working but would love to hear what others think about this approach
to getting object/format specific details printed with llvm-nm.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
Add a testcase where there is an overflow when combining two constants.

I noticed that a proposed optimization would have prevented this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210287 91177308-0d34-0410-b5e6-96231b3b80d8
Adding explicit triples to the ARM jumptable tests


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210288 91177308-0d34-0410-b5e6-96231b3b80d8
Remove duplicate copy of InstrItineraryData from the TargetMachine,
it's already on the subtarget.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210289 91177308-0d34-0410-b5e6-96231b3b80d8
Remove caching of the subtarget for X86FrameLowering.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210290 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed several correctness issues in SeparateConstOffsetFromGEP

Most issues are on mishandling s/zext.

Fixes:

1. When rebuilding new indices, s/zext should be distributed to
sub-expressions. e.g., sext(a +nsw (b +nsw 5)) = sext(a) + sext(b) + 5 but not
sext(a + b) + 5. This also affects the logic of recursively looking for a
constant offset, we need to include s/zext into the context of the searching.

2. Function find should return the bitwidth of the constant offset instead of
always sign-extending it to i64.

3. Stop shortcutting zext'ed GEP indices. LLVM conceptually sign-extends GEP
indices to pointer-size before computing the address. Therefore, gep base,
zext(a + b) != gep base, a + b

Improvements:

1. Add an optimization for splitting sext(a + b): if a + b is proven
non-negative (e.g., used as an index of an inbound GEP) and one of a, b is
non-negative, sext(a + b) = sext(a) + sext(b)

2. Function Distributable checks whether both sext and zext can be distributed
to operands of a binary operator. This helps us split zext(sext(a + b)) to
zext(sext(a) + zext(sext(b)) when a + b does not signed or unsigned overflow.

Refactoring:

Merge some common logic of handling add/sub/or in find.

Testing:

Add many tests in split-gep.ll and split-gep-and-gvn.ll to verify the changes
we made.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210291 91177308-0d34-0410-b5e6-96231b3b80d8
Remove X86Subtarget from the X86FrameLowering constructor since
we can just pass in the values we already know and we're not
caching the subtarget anymore.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210292 91177308-0d34-0410-b5e6-96231b3b80d8
[PPC64LE] Add test case for r210282 commit

Chandler correctly pointed out that I need an LLVM IR test for
r210282, which modified the vperm -> shuffle transform for little
endian PowerPC.  This patch provides that test.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210297 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly set the comdat symbol on COFF.

We extended the .section syntax to allow multiple sections with the
same name but different comdats, but currently we don't make sure that
the output section has that comdat symbol.

That happens to work with the code llc produces currently because it looks like

.section secName, "dr", one_only, "COMDATSym"
.globl COMDATSym
COMDATSym:
....

but that is not very friendly to anyone coding in assembly or even to
llc once we get comdat support in the IR.

This patch changes the coff object writer to make sure the comdat symbol is
output just after the section symbol, as required by the coff spec.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210298 91177308-0d34-0410-b5e6-96231b3b80d8
Fix null dereference with -debug-only=dwarfdebug

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210299 91177308-0d34-0410-b5e6-96231b3b80d8
Fix markup for -debug-only option

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210300 91177308-0d34-0410-b5e6-96231b3b80d8
Allow aliases to be unnamed_addr.

Alias with unnamed_addr were in a strange state. It is stored in GlobalValue,
the language reference talks about "unnamed_addr aliases" but the verifier
was rejecting them.

It seems natural to allow unnamed_addr in aliases:

* It is a property of how it is accessed, not of the data itself.
* It is perfectly possible to write code that depends on the address
of an alias.

This patch then makes unname_addr legal for aliases. One side effect is that
the syntax changes for a corner case: In globals, unnamed_addr is now printed
before the address space.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210302 91177308-0d34-0410-b5e6-96231b3b80d8
config.h: remove clang-specific macro definitions

These had no business in LLVM core.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210307 91177308-0d34-0410-b5e6-96231b3b80d8
Remove clang-specific libxml2 check from CMake

clang's own CMake setup handles this as of r210308.

The CMAKE_CROSSCOMPILING special-case will no longer be hard-coded. This was
clearly site-specific to someone's local configuration and should be passed in
at configure time if needed with e.g. -DLIBXML2_LIBRARIES=... (the libxml2
target I tried here doesn't even support liblzma so it's *way* off).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210309 91177308-0d34-0410-b5e6-96231b3b80d8
Fix PR19657 (scalar loads not combined into vector load)
If we have common uses on separate paths in the tree; process the one with greater common depth first.
This makes sure that we do not assume we need to extract a load when it is actually going to be part of a vectorized tree.

Review: http://reviews.llvm.org/D3800


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210310 91177308-0d34-0410-b5e6-96231b3b80d8