Remove MCObjectDisassembler.cpp as it is untested and unused.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214437 91177308-0d34-0410-b5e6-96231b3b80d8
Fixing CMake problems with MCObjectDisassembler.cpp not existing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214438 91177308-0d34-0410-b5e6-96231b3b80d8
Replaces a few pointers with references in llvm-nm.cpp.

This opens the way for a few std::uinque_ptr cleanups.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214439 91177308-0d34-0410-b5e6-96231b3b80d8
Improve the remark generated when a variable that is used outside the loop is not a reduction or induction variable.

Reviewed by Arnold Schwaighofer


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214440 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Remove MCObjectDisassembler.cpp as it is untested and unused." as it is apparently used, but the build didn't return errors weirdly.

This reverts commits 214437 and 214438.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214444 91177308-0d34-0410-b5e6-96231b3b80d8
Improve the remark generated for -Rpass-missed.

The current remark is ambiguous and makes it sounds like explicitly specifying vectorization will allow the loop to be vectorized. This is not the case. The improved remark directs the user to -Rpass-analysis=loop-vectorize to determine the cause of the pass-miss.

Reviewed by Arnold Schwaighofer`


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214445 91177308-0d34-0410-b5e6-96231b3b80d8
Make sure no loads resulting from load->switch DAGCombine are marked invariant

Currently when DAGCombine converts loads feeding a switch into a switch of
addresses feeding a load the new load inherits the isInvariant flag of the left
side. This is incorrect since invariant loads can be reordered in cases where it
is illegal to reoarder normal loads.

This patch adds an isInvariant parameter to getExtLoad() and updates all call
sites to pass in the data if they have it or false if they don't. It also
changes the DAGCombine to use that data to make the right decision when
creating the new load.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214449 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Modernize work item intrinsics test

Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Matt Arsenault <Matthew.Arsenault@amd.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214451 91177308-0d34-0410-b5e6-96231b3b80d8
Make classof in MemSDNode consistent with MemIntrinsicSDNode

If INTRINSIC_W_CHAIN and INTRINSIC_VOID are MemIntrinsicSDNodes, and a
MemIntrinsicSDNode is a MemSDNode, then INTRINSIC_W_CHAIN and INTRINSIC_VOID
must be MemSDNodes too.

Noticed by inspection.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214455 91177308-0d34-0410-b5e6-96231b3b80d8
X86 MC: Reject invalid segment registers before a memory operand colon

Previously we would execute unreachable during object emission.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214456 91177308-0d34-0410-b5e6-96231b3b80d8
X86 MC: Don't crash on empty memory operand parens

Instead, create an absolute memory operand.

Fixes PR20504.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214457 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the X86 secure guard extensions instructions in assembler (SGX).

This allows assembling the two new instructions, encls and enclu for the
SKX processor model.

Note the diffs are a bigger than what might think, but to fit the new
MRM_CF and MRM_D7 in things in the right places things had to be
renumbered and shuffled down causing a bit more diffs.

rdar://16228228


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214460 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Fix incorrect commute operation in shrink instructions pass

We were commuting the instruction by still shrinking it using the
original opcode.

NOTE: This is a candidate for the 3.5 branch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214463 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Fold immediates when shrinking instructions

This will prevent us from using extra MOV instructions once we prefer
selecting 64-bit instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214464 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Simplify and fix handling of VOP2 in SIInstrInfo::legalizeOperands

We were incorrectly assuming that all VOP2 instructions can read SGPRs
in Src0, but this is not true for instructions that read carry-in from
VCC.

The old logic has been replaced with new logic which checks the defined
register classes of the VOP2 instruction to determine whether or not to
legalize the operands.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214465 91177308-0d34-0410-b5e6-96231b3b80d8
TableGen: Allow AddedComplexity values to be negative

This is useful for cases when stand-alone patterns are preferred to the
patterns included in the instruction definitions.  Instead of requiring
that stand-alone patterns set a larger AddedComplexity value, which
can be confusing to new developers, the allows us to reduce the
complexity of the included patterns to achieve the same result.

There will be test cases for this added to the R600 backend in a
future commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214466 91177308-0d34-0410-b5e6-96231b3b80d8
R600/SI: Do abs/neg folding with ComplexPatterns

Abs/neg folding has moved out of foldOperands and into the instruction
selection phase using complex patterns.  As a consequence of this
change, we now prefer to select the 64-bit encoding for most
instructions and the modifier operands have been dropped from
integer VOP3 instructions.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214467 91177308-0d34-0410-b5e6-96231b3b80d8
MS inline asm: Fix null SMLoc when 'ptr' is missing after dword & co

This improves the diagnostics from the regular assembler, but more
importantly it fixes an assertion when parsing inline assembly.  Test
landing in Clang.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214468 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC] Recognize consecutive memory accesses from intrinsics

When generating unaligned vector loads, we need to search for other loads or
stores nearby offset by one vector width. If we find one, then we know that we
can safely generate another aligned load at that address. Otherwise, we must
generate the next load using an offset of the vector width minus one byte (so
we don't read off the end of the allocation if the base unaligned address
happened to be aligned at runtime). We had previously done this using only
other vector loads and stores, but did not consider the PowerPC-specific vector
load/store intrinsics. Now we'll also consider vector intrinsics. By itself,
this change is a feature enhancement, but is a necessary step toward fixing the
underlying problem behind PR19991.

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