[x86] More cleanup for this test -- simplify the command line.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213991 91177308-0d34-0410-b5e6-96231b3b80d8
IR/UseTest.cpp: Avoid std::to_string() to appease mingw32 bot.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213994 91177308-0d34-0410-b5e6-96231b3b80d8
Update X86/Utils/LLVMBuild.txt corresponding to r213986. "Core" has been introduced.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213995 91177308-0d34-0410-b5e6-96231b3b80d8
[modules] Work around mislayering of MC / Object.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214000 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Add coverage for PMUL* instruction testing on SSE2 as well as
SSE4.1.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214001 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Fix PR20355 (and dups) by not using unsigned multiplication when
signed multiplication is requested. While there is not a difference in
the *low* half of the result, the *high* half (used specifically to
implement the signed division by these constants) certainly is used. The
test case I've nuked was actively asserting wrong code.

There is a delightful solution to doing signed multiplication even when
we don't have it that Richard Smith has crafted, but I'll add the
machinery back and implement that in a follow-up patch. This at least
restores correctness.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214007 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Revert r214007: Fix PR20355 ...

The clever way to implement signed multiplication with unsigned *is
already implemented* and tested and working correctly. The bug is
somewhere else. Re-investigating.

This will teach me to not scroll far enough to read the code that did
what I thought needed to be done.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214009 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Finish switching from CHECK to ALL. This was mistakenly included
in r214007 and then reverted when I backed that (very misguided) patch
out. This recovers the test case cleanup which was good.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214010 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Fix PR20355 (for real). There are many layers to this bug.

The tale starts with r212808 which attempted to fix inversion of the low
and high bits when lowering MUL_LOHI. Sadly, that commit did not include
any positive test cases, and just removed some operations from a test
case where the actual logic being changed isn't fully visible from the
test.

What this commit did was two things. First, it reversed the low and high
results in the formation of the MERGE_VALUES node for the multiple
results. This is entirely correct.

Second it changed the shuffles for extracting the low and high
components from the i64 results of the multiplies to extract them
assuming a big-endian-style encoding of the multiply results. This
second change is wrong. There is no big-endian encoding in x86, the
results of the multiplies are normal v2i64s: when cast to v4i32, the low
i32s are at offsets 0 and 2, and the high i32s are at offsets 1 and 3.

However, the first change wasn't enough to actually fix the bug, which
is (I assume) why the second change was also made. There was another bug
in the MERGE_VALUES formation: we weren't using a VTList, and so were
getting a single result node! When grabbing the *second* result from the
node, we got... well.. colud be anything. I think this *appeared* to
invert things, but had to be causing other problems as well.

Fortunately, I fixed the MERGE_VALUES issue in r213931, so we should
have been fine, right? NOOOPE! Because the core bug was never addressed,
the test in vector-idiv failed when I fixed the MERGE_VALUES node.
Because there are essentially no docs for this node, I had to guess at
how to fix it and tried swapping the operands, restoring the order of
the original code before r212808. While this "fixed" the test case (in
that we produced the write instructions) we were still extracting the
wrong elements of the i64s, and thus PR20355 was still broken.

This commit essentially reverts the big-endian-style extraction part of
r212808 and goes back to the original masks which were correct. Now that
the MERGE_VALUES node formation is also correct, everything works. I've
also included a more detailed test from PR20355 to make sure this stays
fixed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214011 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/test/CodeGen/X86/vector-idiv.ll: Fix for -Asserts.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214015 91177308-0d34-0410-b5e6-96231b3b80d8
X86ShuffleDecode.cpp: Silence a warning. [-Wunused-variable]

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214019 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] When performing post-legalize DAG combining, run the legalizer
over each node in the worklist prior to combining.

This allows the combiner to produce new nodes which need to go back
through legalization. This is particularly useful when generating
operands to target specific nodes in a post-legalize DAG combine where
the operands are significantly easier to express as pre-legalized
operations. My immediate use case will be PSHUFB formation where we need
to build a constant shuffle mask with a build_vector node.

This also refactors the relevant functionality in the legalizer to
support this, and updates relevant tests. I've spoken to the R600 folks
and these changes look like improvements to them. The avx512 change
needs to be investigated, I suspect there is a disagreement between the
legalizer and the DAG combiner there, but it seems a minor issue so
leaving it to be re-evaluated after this patch.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214020 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Simplify the code for handling single-value nodes and add
a missing transfer of debug information (without which tests fail).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214021 91177308-0d34-0410-b5e6-96231b3b80d8
[SDAG] Add an assert that we don't mess up the number of values when
replacing nodes in the legalizer.

This caught a number of bugs for me during development.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214022 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Move intrinsic lowering to separate functions

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214023 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the failing test 'vector-idiv.ll'.
On Darwin the comment character is ##.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214028 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Fix broken test.

There was no check prefix for the instruction lines.
Match what is emitted though, although I'm pretty sure it is
incorrect.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214035 91177308-0d34-0410-b5e6-96231b3b80d8
[ADT] Add a remarkbly useful little helper routine to ArrayRef for
checking whether the ArrayRef is equal to an explicit list of arguments.

This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.

Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214041 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Add a much more powerful framework for combining x86 shuffle
instructions in the legalized DAG, and leverage it to combine long
sequences of instructions to PSHUFB.

Eventually, the other x86-instruction-specific shuffle combines will
probably all be driven out of this routine. But the real motivation is
to detect after we have fully legalized and optimized a shuffle to the
minimal number of x86 instructions whether it is profitable to replace
the chain with a fully generic PSHUFB instruction even though doing so
requires either a load from a constant pool or tying up a register with
the mask.

While the Intel manuals claim it should be used when it replaces 5 or
more instructions (!!!!) my experience is that it is actually very fast
on modern chips, and so I've gon with a much more aggressive model of
replacing any sequence of 3 or more instructions.

I've also taught it to do some basic canonicalization to special-purpose
instructions which have smaller encodings than their generic
counterparts.

There are still quite a few FIXMEs here, and I've not yet implemented
support for lowering blends with PSHUFB (where its power really shines
due to being able to zero out lanes), but this starts implementing real
PSHUFB support even when using the new, fancy shuffle lowering. =]

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