[X86] Convert esp-relative movs of function arguments into pushes, step 1

This handles the simplest case for mov -> push conversion:
1. x86-32 calling convention, everything is passed through the stack.
2. There is no reserved call frame.
3. Only registers or immediates are pushed, no attempt to combine a mem-reg-mem sequence into a single PUSHmm.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223757 91177308-0d34-0410-b5e6-96231b3b80d8
test commit (spelling correction)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223758 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a few instances found in SelectionDAG where we were not handling F16 at parity with F32 and F64.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223760 91177308-0d34-0410-b5e6-96231b3b80d8
AVX-512: Added some comments to ERI scalar intrinsics.
No functional change.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223761 91177308-0d34-0410-b5e6-96231b3b80d8
Use range-based for loops. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223762 91177308-0d34-0410-b5e6-96231b3b80d8
Skip declarations in the case of functions.

This is a revert of r223521 in spirit, if not in content. I am not
sure why declarations ended up in LazilyLinkGlobalValues in the first
place; that will take some more investigation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223763 91177308-0d34-0410-b5e6-96231b3b80d8
Teach instcombine to canonicalize "element extraction" from a load of an
integer and "element insertion" into a store of an integer into actual
element extraction, element insertion, and vector loads and stores.

Previously various parts of LLVM (including instcombine itself) would
introduce integer loads and stores into the code as a way of opaquely
loading and storing "bits". In some cases (such as a memcpy of
std::complex<float> object) we will eventually end up using those bits
in non-integer types. In order for SROA to effectively promote the
allocas involved, it splits these "store a bag of bits" integer loads
and stores up into the constituent parts. However, for non-alloca loads
and tsores which remain, it uses integer math to recombine the values
into a large integer to load or store.

All of this would be "fine", except that it forces LLVM to go through
integer math to combine and split up values. While this makes perfect
sense for integers (and in fact is critical for bitfields to end up
lowering efficiently) it is *terrible* for non-integer types, especially
floating point types. We have a much more canonical way of representing
the act of concatenating the bits of two SSA values in LLVM: a vector
and insertelement. This patch teaching InstCombine to use this
representation.

With this patch applied, LLVM will no longer introduce integer math into
the critical path of every loop over std::complex<float> operations such
as those that make up the hot path of ... oh, most HPC code, Eigen, and
any other heavy linear algebra library.

For the record, I looked *extensively* at fixing this in other parts of
the compiler, but it just doesn't work:
- We really do want to canonicalize memcpy and other bit-motion to
  integer loads and stores. SSA values are tremendously more powerful
  than "copy" intrinsics. Not doing this regresses massive amounts of
  LLVM's scalar optimizer.
- We really do need to split up integer loads and stores of this form in
  SROA or every memcpy of a trivially copyable struct will prevent SSA
  formation of the members of that struct. It essentially turns off
  SROA.
- The closest alternative is to actually split the loads and stores when
  partitioning with SROA, but this has all of the downsides historically
  discussed of splitting up loads and stores -- the wide-store
  information is fundamentally lost. We would also see performance
  regressions for bitfield-heavy code and other places where the
  integers aren't really intended to be split without seemingly
  arbitrary logic to treat integers totally differently.
- We *can* effectively fix this in instcombine, so it isn't that hard of
  a choice to make IMO.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223764 91177308-0d34-0410-b5e6-96231b3b80d8
Improve emacs coding style

Remove setting of default style, this way is not recommended and
means that all the settings have to be duplicated to demonstrate the
c-add-style method which is a much better way of doing it.

Remove the modified date as it is better stored in SVN.

Tweak a few style parameters to make them conform to the actual LLVM
style.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223765 91177308-0d34-0410-b5e6-96231b3b80d8
[test/Transforms/InstCombine/shift.ll] Removed duplicate test cases. NFC.

Removed some duplicate test cases from the file /test/Transforms/InstCombine/shift.ll.

test54 and test57 were duplicates of each other.
test55 and test58 were duplicates of each other.

(Removed test57 and test58)



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223767 91177308-0d34-0410-b5e6-96231b3b80d8
Removal Of Duplicate Test Cases and Addition Of Missing Check Statements


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223768 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Bring some sanity to the x86 CPU processor definitions.

Notably, this adds simple micro-architecture names for the Intel CPU
variants, and defines the old 'core'-based names as aliases. GCC has
started to simplify their documented interface to use these names as
well, so it seems like we can start to converge on a consistent pattern.

I'd appreciate Intel double checking the entries that aren't yet
documented widely, especially Atom (Bonnell and Silvermont), Knights
Landing, and Skylake. But this change shouldn't break any existing
users.

Also, ran clang-format to re-format this code and it actually worked
(modulo a tiny bug) so hopefully we can start to stop thinking about
formatting this stuff.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Add a test for the CPU names that should have been in r223769.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223770 91177308-0d34-0410-b5e6-96231b3b80d8
Fix modified immediate bug reported by MC Hammer.

Instructions of the form [ADD Rd, pc, #imm] are manually aliased
in processInstruction() to use ADR. To accomodate this, mod_imm handling
had to be tweaked a bit. Turns out it was the manual aliasing that must
be tweaked to accommodate mod_imms instead. More information about the
parsed instruction is available at the point where processInstruction()
is invoked, which makes it easier to detect a mod_imm at that point rather
than trying to detect a potential alias when a mod_imm is being prepped.
Added a test case and fixed some white spaces as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223772 91177308-0d34-0410-b5e6-96231b3b80d8
Removing an unused variable to silence a -Wunused-but-set-variable warning. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223773 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Fix the test to actually test things for the CPU names, add the
missing barcelona CPU which that test uncovered, and remove the 32-bit
x86 CPUs which I really wasn't prepared to audit and test thoroughly.

If anyone wants to clean up the 32-bit only x86 CPUs, go for it.

Also, if anyone else wants to try to de-duplicate the AMD CPUs, that'd
be cool, but from the looks of it wouldn't save as much as it did for
the Intel CPUs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223774 91177308-0d34-0410-b5e6-96231b3b80d8
Don't lookup an object symbol name in the module.

Instead, walk the obj symbol list in parallel to find the GV. This shouldn't
change anything on ELF where global symbols are not mangled, but it is a step
toward supporting other object formats.

Gold itself is ELF only, but bfd ld supports COFF and the logic in the gold
plugin could be reused on lld.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223780 91177308-0d34-0410-b5e6-96231b3b80d8
Move method out of line to make buildbot happy.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223781 91177308-0d34-0410-b5e6-96231b3b80d8
[PowerPC 1/4] Little-endian adjustments for VSX loads/stores

This patch addresses the inherent big-endian bias in the lxvd2x,
lxvw4x, stxvd2x, and stxvw4x instructions.  These instructions load
vector elements into registers left-to-right (with the first element
loaded into the high-order bits of the register), regardless of the
endian setting of the processor.  However, these are the only
vector memory instructions that permit unaligned storage accesses, so
we want to use them for little-endian.

To make this work, a lxvd2x or lxvw4x is replaced with an lxvd2x
followed by an xxswapd, which swaps the doublewords.  This works for
lxvw4x as well as lxvd2x, because for lxvw4x on an LE system the
vector elements are in LE order (right-to-left) within each
doubleword.  (Thus after lxvw2x of a <4 x float> the elements will
appear as 1, 0, 3, 2.  Following the swap, they will appear as 3, 2,
0, 1, as desired.)   For stores, an stxvd2x or stxvw4x is replaced
with an stxvd2x preceded by an xxswapd.

Introduction of extra swap instructions provides correctness, but
obviously is not ideal from a performance perspective.  Future patches
will address this with optimizations to remove most of the introduced
swaps, which have proven effective in other implementations.

The introduction of the swaps is performed during lowering of LOAD,
STORE, INTRINSIC_W_CHAIN, and INTRINSIC_VOID operations.  The latter
are used to translate intrinsics that specify the VSX loads and stores
directly into equivalent sequences for little endian.  Thus code that
uses vec_vsx_ld and vec_vsx_st does not have to be modified to be
ported from BE to LE.

We introduce new PPCISD opcodes for LXVD2X, STXVD2X, and XXSWAPD for
use during this lowering step.  In PPCInstrVSX.td, we add new SDType
and SDNode definitions for these (PPClxvd2x, PPCstxvd2x, PPCxxswapd).
These are recognized during instruction selection and mapped to the
correct instructions.

Several tests that were written to use -mcpu=pwr7 or pwr8 are modified
to disable VSX on LE variants because code generation changes with
this and subsequent patches in this set.  I chose to include all of
these in the first patch than try to rigorously sort out which tests
were broken by one or another of the patches.  Sorry about that.

The new test vsx-ldst-builtin-le.ll, and the changes to vsx-ldst.ll,
are disabled until LE support is enabled because of breakages that
occur as noted in those tests.  They are re-enabled in patch 4/4.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223783 91177308-0d34-0410-b5e6-96231b3b80d8
Move function to obtain branch weights into the BranchInst class. NFC.

Make this function available to other parts of LLVM.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223784 91177308-0d34-0410-b5e6-96231b3b80d8
Add more pattern matchers for compares, instructions, and BinaryOperators. NFC.

Add a few more matchers to make the code in the next commit more compact.

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