[x86] Teach the instruction lowering to add comments describing constant
pool data being loaded into a vector register.

The comments take the form of:

  # ymm0 = [a,b,c,d,...]
  # xmm1 = <x,y,z...>

The []s are used for generic sequential data and the <>s are used for
specifically ConstantVector loads. Undef elements are printed as the
letter 'u', integers in decimal, and floating point values as floating
point values. Suggestions on improving the formatting or other aspects
of the display are very welcome.

My primary use case for this is to be able to FileCheck test masks
passed to vector shuffle instructions in-register. It isn't fantastic
for that (no decoding special zeroing semantics or other tricks), but it
at least puts the mask onto an instruction line that could reasonably be
checked. I've updated many of the new vector shuffle lowering tests to
leverage this in their test cases so that we're actually checking the
shuffle masks remain as expected.

Before implementing this, I tried a *bunch* of different approaches.
I looked into teaching the MCInstLower code to scan up the basic block
and find a definition of a register used in a shuffle instruction and
then decode that, but this seems incredibly brittle and complex.
I talked to Hal a lot about the "right" way to do this: attach the raw
shuffle mask to the instruction itself in some form of unencoded
operands, and then use that to emit the comments. I still think that's
the optimal solution here, but it proved to be beyond what I'm up for
here. In particular, it seems likely best done by completing the
plumbing of metadata through these layers and attaching the shuffle mask
in metadata which could have fully automatic dropping when encoding an
actual instruction.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218377 91177308-0d34-0410-b5e6-96231b3b80d8
Replace a hand-written suffix compare with std::lexicographical_compare.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218380 91177308-0d34-0410-b5e6-96231b3b80d8
Silencing an "enumeral and non-enumeral type in conditional expression" warning. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218381 91177308-0d34-0410-b5e6-96231b3b80d8
[Thumb] 32-bit encodings of 'cps' are not valid for v7M

v7M only allows the 16-bit encoding of the 'cps' (Change Processor
State) instruction, and does not have the 32-bit encoding which is
valid from v6T2 onwards.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218382 91177308-0d34-0410-b5e6-96231b3b80d8
[Thumb] Make load/store optimizer less conservative.

If it's safe to clobber the condition flags, we can do a few extra things:
it's then possible to reset the base register writeback using a SUBS, so
we can try to merge even if the base register isn't dead after the merged
instruction.

This is effectively a (heavily bug-fixed) rewrite of r208992.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218386 91177308-0d34-0410-b5e6-96231b3b80d8
Fix assertion in LICM doFinalization()

The doFinalization method checks that the LoopToAliasSetMap is
empty. LICM populates that map as it runs through the loop nest,
deleting the entries for child loops as it goes. However, if a child
loop is deleted by another pass (e.g. unrolling) then the loop will
never be deleted from the map because LICM walks the loop nest to
find entries it can delete.

The fix is to delete the loop from the map and free the alias set
when the loop is deleted from the loop nest.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218387 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the RelocVisitor::visit method

This change replaces the brittle if/else chain of string comparisons
with a switch statement on the detected target triple, removing the
need for testing arbitrary architecture names returned from
getFileFormatName, whose primary purpose seems to be for display
(user-interface) purposes. The visitor now takes a reference to the
object file, rather than its arbitrary file format name to figure out
whether the file is a 32 or 64-bit object file and what the detected
target triple is.

A set of tests have been added to help show that the refactoring processes
relocations for the same targets as the original code.

Patch by Charlie Turner.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218388 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for ARM and AArch64 BE object files

This change fixes the ARM and AArch64 relocation visitors in
RelocVisitor.  They were unconditionally assuming the object data are
little-endian.  Tests have been added to ensure that the
llvm-dwarfdump utility does not crash when processing big-endian
object files.

Patch by Charlie Turner.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218389 91177308-0d34-0410-b5e6-96231b3b80d8
Report endianness in output of {dwarf, obj}dump

For biendian targets like ARM and AArch64, it is useful to have the
output of the llvm-dwarfdump and llvm-objdump report the endianness
used when the object files were generated.

Patch by Charlie Turner.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218391 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Refactor the RelocVisitor::visit method"

This reverts commit faac033f7364bb4226e22c8079c221c96af10d02.

The test depends on all targets to be enabled in llc in order to pass,
and needs to be rewritten/refactored to not have that dependency.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218393 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Report endianness in output of {dwarf, obj}dump"

This reverts commit r218391 as it depends on r218388 and r218389

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218397 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Add support for ARM and AArch64 BE object files"

This reverts commit r218389 as it depends on r218388.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218398 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Factor out the logic to generically decombose a vector shuffle
into unblended shuffles and a blend.

This is the consistent fallback for the lowering paths that have fast
blend operations available, and its getting quite repetitive.

No functionality changed.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218399 91177308-0d34-0410-b5e6-96231b3b80d8
Adding #ifdef around TermColorMutex based on feedback from Craig Topper.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218401 91177308-0d34-0410-b5e6-96231b3b80d8
pass environment when invoking llvm-config from lit.cfg

Use the same environment when invoking llvm-config from lit.cfg as
will be used when running tests, so that ASAN_OPTIONS, INCLUDE, etc.
are present.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218403 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the RelocVisitor::visit method

This change replaces the brittle if/else chain of string comparisons
with a switch statement on the detected target triple, removing the
need for testing arbitrary architecture names returned from
getFileFormatName, whose primary purpose seems to be for display
(user-interface) purposes. The visitor now takes a reference to the
object file, rather than its arbitrary file format name to figure out
whether the file is a 32 or 64-bit object file and what the detected
target triple is.

A set of tests have been added to help show that the refactoring processes
relocations for the same targets as the original code.

Patch by Charlie Turner.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218406 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for ARM and AArch64 BE object files

This change fixes the ARM and AArch64 relocation visitors in
RelocVisitor.  They were unconditionally assuming the object data are
little-endian.  Tests have been added to ensure that the
llvm-dwarfdump utility does not crash when processing big-endian
object files.

Patch by Charlie Turner.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218407 91177308-0d34-0410-b5e6-96231b3b80d8
Report endianness in output of {dwarf, obj}dump

For biendian targets like ARM and AArch64, it is useful to have the
output of the llvm-dwarfdump and llvm-objdump report the endianness
used when the object files were generated.

Patch by Charlie Turner.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218408 91177308-0d34-0410-b5e6-96231b3b80d8
Revert r218380. This was breaking Apple internal build bots.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218409 91177308-0d34-0410-b5e6-96231b3b80d8
XFAIL reloc test on x86/hexagon

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