Allwo bitcast + struct GEP transform to work with addrspacecast

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215467 91177308-0d34-0410-b5e6-96231b3b80d8
[AVX512] Handle valign masking intrinsic via C++ lowering

I think that this will scale better in most cases than adding a Pat<> for each
mapping from the intrinsic DAG to the intruction (i.e. rri, rrik, rrikz).  We
can just lower to the SDNode and have the resulting DAG be matches by the DAG
patterns.

Alternatively (long term), we could keep the Pat<>s but generate them via the
new AVX512_masking multiclass.  The difficulty is that in order to formulate
that we would have to concatenate DAGs.  Currently this is only supported if
the operators of the input DAGs are identical.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215473 91177308-0d34-0410-b5e6-96231b3b80d8
Remove a condition that can never be true, as wittnessed by the assert
above.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215477 91177308-0d34-0410-b5e6-96231b3b80d8
APInt: Make self-move-assignment a no-op to fix stage3 clang-cl

It's not clear what the semantics of a self-move should be.  The
consensus appears to be that a self-move should leave the object in a
moved-from state, which is what our existing move assignment operator
does.

However, the MSVC 2013 STL will perform self-moves in some cases.  In
particular, when doing a std::stable_sort of an already sorted APSInt
vector of an appropriate size, one of the merge steps will self-move
half of the elements.

We don't notice this when building with MSVC, because MSVC will not
synthesize the move assignment operator for APSInt.  Presumably MSVC
does this because APInt, the base class, has user-declared special
members that implicitly delete move special members.  Instead, MSVC
selects the copy-assign operator, which defends against self-assignment.
Clang, on the other hand, selects the move-assign operator, and we get
garbage APInts.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215478 91177308-0d34-0410-b5e6-96231b3b80d8
Fix -Wsign-compare warnings

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215483 91177308-0d34-0410-b5e6-96231b3b80d8
[AVX512] Verify the code generated for the intrinsic _mm512_broadcastsd_pd

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215487 91177308-0d34-0410-b5e6-96231b3b80d8
Fix classof for ISD::INTRINSIC_W_CHAIN and INTRINSIC_VOID

Unfortunately, our use of the SDNode class hierarchy for INTRINSIC_W_CHAIN and
INTRINSIC_VOID nodes is somewhat broken right now. These nodes sometimes are
used for memory intrinsics (those with MachineMemOperands), and sometimes not.
When not, the nodes are not created as instances of MemIntrinsicSDNode, but
rather created as some other subclass of SDNode using DAG::getNode. When they
are memory intrinsics, they are created using DAG::getMemIntrinsicNode as
instances of MemIntrinsicSDNode. MemIntrinsicSDNode is a subclass of
MemSDNode, but prior to r214452, we had a non-self-consistent setup whereby
MemIntrinsicSDNode::classof on INTRINSIC_W_CHAIN and INTRINSIC_VOID would
return true but MemSDNode::classof on INTRINSIC_W_CHAIN and INTRINSIC_VOID
would return false. In r214452, MemSDNode::classof was changed to return true
for INTRINSIC_W_CHAIN and INTRINSIC_VOID, which is now self-consistent. The
problem is that neither the pre-r214452 logic and the post-r214452 logic are
really right. The truth is that not all INTRINSIC_W_CHAIN and INTRINSIC_VOID
nodes are instances of MemIntrinsicSDNode (or MemSDNode for that matter), and
the return value from classof needs to reflect that. This was broken before
r214452 (because MemIntrinsicSDNode::classof always returned true), and was
broken afterward (because MemSDNode::classof also always returned true), and
will now be correct.

The minimal solution is to grab one of the SubclassData bits (there is one left
for MemIntrinsicSDNode nodes) and use it to store whether or not a particular
INTRINSIC_W_CHAIN or INTRINSIC_VOID is really an instance of
MemIntrinsicSDNode or not. Doing this allows both MemIntrinsicSDNode::classof
and MemSDNode::classof to return the correct answer for the underlying object
for both the memory-intrinsic and non-memory-intrinsic cases.

This fixes the problem that r214452 created in the SelectionDAGDumper (thanks
to Matt Arsenault for pointing it out).

Because PowerPC does not implement getTgtMemIntrinsic, this change breaks
test/CodeGen/PowerPC/unal-altivec-wint.ll. I've XFAILed it for now, and will
fix it in a follow-up commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215511 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Implement PPCTargetLowering::getTgtMemIntrinsic

This implements PPCTargetLowering::getTgtMemIntrinsic for Altivec load/store
intrinsics. As with the construction of the MachineMemOperands for the
intrinsic calls used for unaligned load/store lowering, the only slight
complication is that we need to represent a larger memory range than the
loaded/stored value-type size (because the address is rounded down to an
aligned address, and we need to conservatively represent the entire possible
range of the actual access). This required adding an extra size field to
TargetLowering::IntrinsicInfo, and this was done in a way that required no
modifications to other targets (the size defaults to the store size of the
provided memory data type).

This fixes test/CodeGen/PowerPC/unal-altivec-wint.ll (so it can be un-XFAILed).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215512 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Rewrite a core part of the new vector shuffle lowering to handle
one pesky test case correctly.

This test case caused the old code to infloop occilating between solving
the low-half and the high-half. The 'side balancing' part of
single-input v8 shuffle lowering didn't handle the one pattern which can
cause it to occilate. Fortunately the fuzz testing found this case.
Unfortuately it was *terrible* to handle. I'm really sorry for the
amount and density of the code here, I'd love suggestions on how to
simplify it. I feel like there *must* be a simpler form here, but after
a lot of days I've not found it. This is the only one I've found that
even works. I've added the one pesky test case along with some nice
comments explaining the core problem that we have to solve here.

So far this has survived approximately 32k test cases. More strenuous
fuzzing commencing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215519 91177308-0d34-0410-b5e6-96231b3b80d8
[shuffle] Tweak the shuffle fuzzer to support bigger seeds. I'm
currently using UUIDs to seed this in order to scan a bigger range.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215521 91177308-0d34-0410-b5e6-96231b3b80d8
Fix examples of "named metadata" (some of which isn't named).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215522 91177308-0d34-0410-b5e6-96231b3b80d8
[NVPTX] Remove MemIntrinsicSDNode/MemSDNode duplicate checking

As of r214452, isa<MemSDNode> will return true for nodes for which
isa<MemIntrinsicSDNode> will return true (classof now respects the actual class
hierarchy). So we no longer need to check for both MemIntrinsicSDNode and
MemSDNode separately.

No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215523 91177308-0d34-0410-b5e6-96231b3b80d8
InstCombine: Combine (xor (or %a, %b) (xor %a, %b)) to (add %a, %b)

Correctness proof of the transform using CVC3-

$ cat t.cvc
A, B : BITVECTOR(32);
QUERY BVXOR(A | B, BVXOR(A,B) ) = A & B;

$ cvc3 t.cvc
Valid.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215524 91177308-0d34-0410-b5e6-96231b3b80d8
AVX-512: Fixed a bug in shufflevector lowering.
PALIGNR instruction does not exist in AVX-512F set.
Added a test.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215526 91177308-0d34-0410-b5e6-96231b3b80d8
[shuffle] Teach the shuffle fuzzer to fuzz blends, including forming
a tree of inputs to blend iteratively together.

This required a pretty substantial rewrite of the innards. The number of
shuffle instructions is now bounded in terms of tree-height. There is
a flag to disable blends so that its still possible to test single input
shuffles. I've also improved various aspects of how the test program is
generated, primarily to simplify the test harness and allow some
optimizations to clean up how we actually check the results and build up
the inputs.

Again, apologies for my likely horrible use of Python... But hey, it
works! (Ish?)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215530 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r215415 which causse MSan to crash on a great deal of C++ code.
I've followed up on the original commit as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215532 91177308-0d34-0410-b5e6-96231b3b80d8
[shuffle] Make the seed an optional component and add support for
letting the python very directly compute a UUID.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215533 91177308-0d34-0410-b5e6-96231b3b80d8
Re-commit: [mips] Implement .ent, .end, .frame, .mask and .fmask.

Patch by Matheus Almeida and Toma Tabacu

The lld test failure on the previous attempt to commit was caused by the
addition of the .pdr section causing the offsets it was checking to change.
This has been fixed by removing the .ent/.end directives from that test since
they weren't really needed.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215535 91177308-0d34-0410-b5e6-96231b3b80d8
[SKX] Extended non-temporal load/store instructions for AVX512VL subsets.

Added avx512_movnt_vl multiclass for handling 256/128-bit forms of instruction.
Added encoding and lowering tests.

Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com>


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215536 91177308-0d34-0410-b5e6-96231b3b80d8
Silence a -Wparenthesis warning with these asserts. NFC.

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