[x86] Teach the new vector shuffle lowering to use 'punpcklwd' and
'punpckhwd' instructions when suitable rather than falling back to the
generic algorithm.

While we could canonicalize to these patterns late in the process, that
wouldn't help when the freedom to use them is only visible during
initial lowering when undef lanes are well understood. This, it turns
out, is very important for matching the shuffle patterns that are used
to lower sign extension. Fixes a small but relevant regression in
gcc-loops with the new lowering.

When I changed this I noticed that several 'pshufd' lowerings became
unpck variants. This is bad because it removes the ability to freely
copy in the same instruction. I've adjusted the widening test to handle
undef lanes correctly and now those will correctly continue to use
'pshufd' to lower. However, this caused a bunch of churn in the test
cases. No functional change, just churn.

Both of these changes are part of addressing a general weakness in the
new lowering -- it doesn't sufficiently leverage undef lanes. I've at
least a couple of patches that will help there at least in an academic
sense.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217752 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Undo a flawed transform I added to form UNPCK instructions when
AVX is available, and generally tidy up things surrounding UNPCK
formation.

Originally, I was thinking that the only advantage of PSHUFD over UNPCK
instruction variants was its free copy, and otherwise we should use the
shorter encoding UNPCK instructions. This isn't right though, there is
a larger advantage of being able to fold a load into the operand of
a PSHUFD. For UNPCK, the operand *must* be in a register so it can be
the second input.

This removes the UNPCK formation in the target-specific DAG combine for
v4i32 shuffles. It also lifts the v8 and v16 cases out of the
AVX-specific check as they are potentially replacing multiple
instructions with a single instruction and so should always be valuable.
The floating point checks are simplified accordingly.

This also adjusts the formation of PSHUFD instructions to attempt to
match the shuffle mask to one which would fit an UNPCK instruction
variant. This was originally motivated to allow it to match the UNPCK
instructions in the combiner, but clearly won't now.

Eventually, we should add a MachineCombiner pass that can form UNPCK
instructions post-RA when the operand is known to be in a register and
thus there is no loss.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217755 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a non-virtual destructor warning introduced in r217747.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217756 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Teach the x86 DAG combiner to form MOVSLDUP and MOVSHDUP
instructions when it finds an appropriate pattern.

These are lovely instructions, and its a shame to not use them. =] They
are fast, and can hand loads folded into their operands, etc.

I've also plumbed the comment shuffle decoding through the various
layers so that the test cases are printed nicely.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217758 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Teach the x86 DAG combiner to form UNPCKLPS and UNPCKHPS
instructions from the relevant shuffle patterns.

This is the last tweak I'm aware of to generate essentially perfect
v4f32 and v2f64 shuffles with the new vector shuffle lowering up through
SSE4.1. I'm sure I've missed some and it'd be nice to check since v4f32
is amenable to exhaustive exploration, but this is all of the tricks I'm
aware of.

With AVX there is a new trick to use the VPERMILPS instruction, that's
coming up in a subsequent patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217761 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Add an explicit SSE3 run to this test and flesh out a bunch of
missing specific checks.

While there is a lot of redundancy here where all-but-one mode use the
same code generation, I'd rather have each variant spelled out and
checked so that readers aren't misled by an omission in the test suite.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217765 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Begin emitting PBLENDW instructions for integer blend operations
when SSE4.1 is available.

This removes a ton of domain crossing from blend code paths that were
ending up in the floating point code path.

This is just the tip of the iceberg though. The real switch is for
integer blend lowering to more actively rely on this instruction being
available so we don't hit shufps at all any longer. =] That will come in
a follow-up patch.

Another place where we need better support is for using PBLENDVB when
doing so avoids the need to have two complementary PSHUFB masks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217767 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Marked the DADDiu instruction aliases as MIPS III.

Patch by Vasileios Kalintiris.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217770 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Use early exit in MipsAsmParser::matchCPURegisterName(). NFC.

Patch by Vasileios Kalintiris.

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



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217774 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Enable named operand table for MTBUF

There is already code trying to use it for getting
the offset.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217775 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Fix promote alloca pass breaking addrspacecast

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217776 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add preliminary support for flat address space

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217777 91177308-0d34-0410-b5e6-96231b3b80d8
Use IntrusiveRefCntPtr to manage the lifetime of BitCodeAbbrevs.

This doesn't change the interface or gives additional safety but removes
a ton of retain/release boilerplate.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217778 91177308-0d34-0410-b5e6-96231b3b80d8
Spell out the template args for compilers having issues with the injected class
name.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217780 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Add some mubuf testcases.

I noticed some odd looking cases where addr64 wasn't set
when storing to a pointer in an SGPR. This seems to be intentional,
and partially tested already.

The documentation seems to describe addr64 in terms of which registers
addressing modifiers come from, but I would expect to always need
addr64 when using 64-bit pointers. If no offset is applied,
it makes sense to not need to worry about doing a 64-bit add
for the final address. A small immediate offset can be applied,
so is it OK to not have addr64 set if a carry is necessary when adding
the base pointer in the resource to the offset?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217785 91177308-0d34-0410-b5e6-96231b3b80d8
Add unit test for r217454


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217786 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Make sure double vector fmul is tested

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217787 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Prefer selecting more e64 instruction forms.

Add some more tests to make sure better operand
choices are still made. Leave some cases that seem
to have no reason to ever be e64 alone.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217789 91177308-0d34-0410-b5e6-96231b3b80d8
[MCJIT] Start Stringref-izing the ExecutionEngine interface.

More methods to follow.

Using StringRef allows us the EE interface to work with more string types
without forcing construction of std::strings.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217794 91177308-0d34-0410-b5e6-96231b3b80d8
Use dyn_cast<> instead of isa<> and cast<>

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