[SystemZ] Add conditional store patterns

Add pseudo conditional store instructions, so that we use:

    branch foo:
    store
foo:

instead of:

    load
    branch foo:
    move
foo:
    store

z196 has real 32-bit and 64-bit conditional stores, but we don't use
any z196 instructions yet.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185065 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Allow immediate moves to be rematerialized


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185068 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Allow LA and LARL to be rematerialized


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185069 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Fix some embarrassing test typos


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185070 91177308-0d34-0410-b5e6-96231b3b80d8
Don't cast away constness.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185072 91177308-0d34-0410-b5e6-96231b3b80d8
Add a Subtarget feature 'v8fp' to the ARM backend.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185073 91177308-0d34-0410-b5e6-96231b3b80d8
Use MCFillFragment for zero-initialized data.
It fixes PR16338 (ICE when compiling very large two-dimensional array).

Differential Revision: http://llvm-reviews.chandlerc.com/D1043


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185080 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Use vectorized loop invariant gep index anchored in loop

Use vectorized instruction instead of original instruction anchored in the
original loop.

Fixes PR16452 and t2075.c of PR16455.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185081 91177308-0d34-0410-b5e6-96231b3b80d8
R600: Remove alu-split.ll test

The purpose of this test was to check boundary conditions for the size
of an ALU clause.  This test is very sensitive to changes to the
optimizer or scheduler, because it requires an exact number of ALU
instructions in order to remain valid.  It's not good to have a test
this sensitive, because it is confusing to developers who implement
optimizations and then 'break' the test.

I'm not sure if there is a good way to test these limits using lit, but
if I can come up with replacement test that isn't as sensitive I'll add
it back to the tree.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185084 91177308-0d34-0410-b5e6-96231b3b80d8
CostModel: improve the cost model for load/store of non power-of-two types such as <3 x float>, which are popular in graphics.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185085 91177308-0d34-0410-b5e6-96231b3b80d8
Get rid of the unused class member.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185086 91177308-0d34-0410-b5e6-96231b3b80d8
[Support/Registry.h] Include llvm/Support/Compiler.h.

Because Registry.h is using the LLVM_DELETED_FUNCTION macro.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185087 91177308-0d34-0410-b5e6-96231b3b80d8
Improve the compression of the tablegen DiffLists by introducing a new sort
algorithm when assigning EnumValues to the synthesized registers.

The current algorithm, LessRecord, uses the StringRef compare_numeric
function.  This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:

  T1
  T1_W
  T1_X
  T1_XYZW
  T1_Y
  T1_Z
  T2
  T2_W
  T2_X
  T2_XYZW
  T2_Y
  T2_Z

In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another.  However, in other parts
of the register bank, the scaling factors are different:

dEnum/dN = 5:
  KC0_128_W
  KC0_128_X
  KC0_128_XYZW
  KC0_128_Y
  KC0_128_Z
  KC0_129_W
  KC0_129_X
  KC0_129_XYZW
  KC0_129_Y
  KC0_129_Z

The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'.  This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1.  For example, the registers are now sorted as
follows:

  T1
  T2
  T3
  ...
  T0_W
  T1_W
  T2_W
  ...
  T0_X
  T1_X
  T2_X
  ...
  KC0_128_W
  KC0_129_W
  KC0_130_W
  ...

For the Mips and R600 I see a 19% and 6% reduction in size, respectively.  I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes).  I suspect there will be even
greater wins for targets with larger register files.

Patch reviewed by Jakob.
rdar://14006013


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185094 91177308-0d34-0410-b5e6-96231b3b80d8
[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.

The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.

I also fixed up all of the references to this constructor (which were
only in LLVM).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185095 91177308-0d34-0410-b5e6-96231b3b80d8
Remove unnecessary conditional checks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185096 91177308-0d34-0410-b5e6-96231b3b80d8
LoopVectorize: Cache edge masks created during if-conversion

Otherwise, we end up with an exponential IR blowup.
Fixes PR16472.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185097 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float."

This reverts commit r185095. This is causing a FileCheck failure on
the 3dnow intrinsics on at least the mips/ppc bots but not on the x86
bots.

Reverting while I figure out what is going on.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185099 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.""

This reverts commit r185099.

Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.

Since:

1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),

I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185111 91177308-0d34-0410-b5e6-96231b3b80d8
At the request of Richard Smith, swapped the order of cold/builtin so it is in alphabetical order.

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