Fix creating illegal setcc cond codes.

If GT/UGT or LT/ULT were set to expand, a comparison
with a constant would replace it with the illegal
cond code.

There are several more places later in this function that
will have the same basic problem.

Theoretically R600 should hit this problem for a test,
but for some reason it doesn't.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204727 91177308-0d34-0410-b5e6-96231b3b80d8
ScalarEvolution: Compute exit counts for loops with a power-of-2 step.

If we have a loop of the form
for (unsigned n = 0; n != (k & -32); n += 32) {}
then we know that n is always divisible by 32 and the loop must
terminate. Even if we have a condition where the loop counter will
overflow it'll always hold this invariant.

PR19183. Our loop vectorizer creates this pattern and it's also
occasionally formed by loop counters derived from pointers.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204728 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Add failing testcase for <3 x i32> stores.

This is supposed to have the same store size and alignment as <4 x i32>,
but currently is split into a 64-bit and 32-bit store.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204729 91177308-0d34-0410-b5e6-96231b3b80d8
Add missing slash to make the doxygen output less confusing.

PR19187.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204731 91177308-0d34-0410-b5e6-96231b3b80d8
Reuse earlier variables to make it clear the types involved in the cast.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204732 91177308-0d34-0410-b5e6-96231b3b80d8
[InstCombine] Don't fold bitcast into store if it would need addrspacecast

Summary:
Previously the code didn't check if the before and after types for the
store were pointers to different address spaces. This resulted in
instcombine using a bitcast to convert between pointers to different
address spaces, causing an assertion due to the invalid cast.

It is not be appropriate to use addrspacecast this case because it is
not guaranteed to be a no-op cast. Instead bail out and do not do the
transformation.

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D3117

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204733 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Factor out new helper getPSHUFB

I found three implementations of this.  This splits it out into a new function
and uses it from the three places.

My plan is to add a fourth use when lowering a vector_shuffle:v16i16.

Compared the assembly output of test/CodeGen/X86 before and after.

The only change is due to how the first PSHUFB was generated in
LowerVECTOR_SHUFFLEv8i16.  If the shuffle mask specified undef (i.e. -1), the
old implementation would write -1 * 2 and -1 * 2 + 1 (254 and 255) in the
control mask.  Now we write 0x80.  These are of course interchangeable since
bit 7 decides if a constant zero is written in the result byte.  The other
instances of this code use 0x80 consistently.

Related to <rdar://problem/16167303>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204734 91177308-0d34-0410-b5e6-96231b3b80d8
[X86] Generate VPSHUFB for in-place v16i16 shuffles

This used to resort to splitting the 256-bit operation into two 128-bit
shuffles and then recombining the results.

Fixes <rdar://problem/16167303>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204735 91177308-0d34-0410-b5e6-96231b3b80d8
[DAG] Keep the opaque constant flag when performing unary constant folding operations.

Usually opaque constants shouldn't be folded, unless they are simple unary
operations that don't create new constants. Although this shouldn't drop the
opaque constant flag. This commit fixes this.

Related to <rdar://problem/14774662>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204737 91177308-0d34-0410-b5e6-96231b3b80d8
[Stackmaps][X86TTI] Fix think-o in getIntImmCost calculation.

The cost for the first four stackmap operands was always TCC_Free.
This is only true for the first two operands. All other operands
are TCC_Free if they are within 64bit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204738 91177308-0d34-0410-b5e6-96231b3b80d8
[X86TTI] Make constant base pointers for getElementPtr opaque.

If getElementPtr uses a constant as base pointer, then make the constant opaque.
This prevents constant folding it with the offset. The offset can usually be
encoded in the load/store instruction itself and the base address doesn't have
to be rematerialized several times.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204739 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Use const in MachineBlockFrequencyInfo

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204740 91177308-0d34-0410-b5e6-96231b3b80d8
blockfreq: Implement Pass::releaseMemory()

Implement Pass::releaseMemory() in BlockFrequencyInfo and
MachineBlockFrequencyInfo.  Just delete the private implementation when
not in use.  Switch to a std::unique_ptr to make the logic more clear.

<rdar://problem/14292693>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204741 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Move computeMaskedBitsForTargetNode out of AMDILISelLowering.cpp

Remove handling of select_cc, since it makes no sense to be there. This
now does nothing, but I'll be adding some handling of other target nodes
soon.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204743 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Add a TableGen relation for A-type and M-type VSX FMA instructions

TableGen will create a lookup table for the A-type FMA instructions providing
their corresponding M-form opcodes. This will be used by upcoming commits.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204746 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Correct commutable indices for VSX FMA instructions

Although the first two operands are the ones that can be swapped, the tied
input operand is listed before them, so we need to adjust for that.

I have a test case for this, but it goes along with an upcoming commit (so it
will come soon).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204748 91177308-0d34-0410-b5e6-96231b3b80d8
[Constant Hoisting] Make the constant candidate map local to the collectConstantCandidates method.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204758 91177308-0d34-0410-b5e6-96231b3b80d8
[configure/make] Propagate names of build host tools when making BuildTools

When cross-compiling LLVM itself the configure/make scripts get confused when
creating the needed build host tools.  For example, building and configuring
like:

  CC_FOR_BUILD='i686-pc-linux-gnu-gcc' CXX_FOR_BUILD='i686-pc-linux-gnu-g++'
  CXX='i686-mingw32-g++' CC='i686-mingw32-gcc' LD='i686-mingw32-ld' /scratch
  /meadori/llvm-trunk/src/trunk/configure --host=i686-mingw32

  CC_FOR_BUILD='i686-pc-linux-gnu-gcc' CXX_FOR_BUILD='i686-pc-linux-gnu-g++'
  CXX='i686-mingw32-g++' CC='i686-mingw32-gcc' LD='i686-mingw32-ld' make

causes the following build break:

  checking whether the C compiler works... configure: error: cannot run C
  compiled programs.
  If you meant to cross compile, use `--host'.
  See `config.log' for more details.

The 'config.log' shows that i686-mingw32-gcc is being used to create
executables for the build host.

This patch fixes the problem by propogating the names of the build host
tools via BUILD_* when configuring/making BuildTools.

Original patch by Ekaterina Sanina.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204760 91177308-0d34-0410-b5e6-96231b3b80d8
Use Endian.h to simplify this code a bit.

While at it, factor some logic into FragmentWriter. This will allow more code
to be factored out of the fairly large ELFObjectWriter.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204765 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/test/DebugInfo/empty.ll: Suppress crash for targeting pecoff while investigating.

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