Merging r203146:

------------------------------------------------------------------------
r203146 | reid | 2014-03-06 14:19:12 -0500 (Thu, 06 Mar 2014) | 6 lines

MS asm: The initial dot in struct access is optional

Fixes PR18994.

Tests, once again, in that other repository.  =P

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205814 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r198425:

------------------------------------------------------------------------
r198425 | dpeixott | 2014-01-03 12:20:01 -0500 (Fri, 03 Jan 2014) | 33 lines

Fix loop rerolling pass failure with non-consant loop lower bound

The loop rerolling pass was failing with an assertion failure from a
failed cast on loops like this:

  void foo(int *A, int *B, int m, int n) {
    for (int i = m; i < n; i+=4) {
      A[i+0] = B[i+0] * 4;
      A[i+1] = B[i+1] * 4;
      A[i+2] = B[i+2] * 4;
      A[i+3] = B[i+3] * 4;
    }
  }

The code was casting the SCEV-expanded code for the new
induction variable to a phi-node. When the loop had a non-constant
lower bound, the SCEV expander would end the code expansion with an
add insted of a phi node and the cast would fail.

It looks like the cast to a phi node was only needed to get the
induction variable value coming from the backedge to compute the end
of loop condition. This patch changes the loop reroller to compare
the induction variable to the number of times the backedge is taken
instead of the iteration count of the loop. In other words, we stop
the loop when the current value of the induction variable ==
IterationCount-1. Previously, the comparison was comparing the
induction variable value from the next iteration == IterationCount.

This problem only seems to occur on 32-bit targets. For some reason,
the loop is not rerolled on 64-bit targets.

PR18290

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205817 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r199570:

------------------------------------------------------------------------
r199570 | aschwaighofer | 2014-01-18 22:18:31 -0500 (Sat, 18 Jan 2014) | 11 lines

LoopVectorizer: A reduction that has multiple uses of the reduction value is not
a reduction.

Really. Under certain circumstances (the use list of an instruction has to be
set up right - hence the extra pass in the test case) we would not recognize
when a value in a potential reduction cycle was used multiple times by the
reduction cycle.

Fixes PR18526.
radar://15851149

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205818 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r199763:

------------------------------------------------------------------------
r199763 | hfinkel | 2014-01-21 15:15:58 -0500 (Tue, 21 Jan 2014) | 9 lines

Fix pointer info on PPC byval stores

For PPC64 SVR (and Darwin), the stores that take byval aggregate parameters
from registers into the stack frame had MachinePointerInfo objects with
incorrect offsets. These offsets are relative to the object itself, not to the
stack frame base.

This fixes self hosting on PPC64 when compiling with -enable-aa-sched-mi.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205819 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r199832:

------------------------------------------------------------------------
r199832 | rafael.espindola | 2014-01-22 15:20:52 -0500 (Wed, 22 Jan 2014) | 11 lines

Fix pr18515.

My understanding (from reading just the llvm code) is that
* most ppc cpus have a "sync n" instruction and an msync alias that is
* "sync 0".
* "book e" cpus instead have a msync instruction and not the more
general "sync n"

This patch reflects that in the .td files, allowing a single codepath
for
asm ond obj streamer and incidentelly fixes a crash when EmitRawText was
called on a obj streamer.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205820 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r200288:

------------------------------------------------------------------------
r200288 | hfinkel | 2014-01-28 00:32:58 -0500 (Tue, 28 Jan 2014) | 5 lines

Handle spilling the PPC GPRC_NOR0 register class

GPRC_NOR0 is not a subclass of GPRC (because it also contains the ZERO pseudo
register). As a result, we also need to check for it in the spilling code.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205821 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r202192:

------------------------------------------------------------------------
r202192 | hfinkel | 2014-02-25 15:51:50 -0500 (Tue, 25 Feb 2014) | 5 lines

Account for 128-bit integer operations in PPCCTRLoops

We need to abort the formation of counter-register-based loops where there are
128-bit integer operations that might become function calls.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205822 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r203054:

------------------------------------------------------------------------
r203054 | hfinkel | 2014-03-05 20:28:23 -0500 (Wed, 05 Mar 2014) | 7 lines

The PPC global base register cannot be r0

The global base register cannot be r0 because it might end up as the first
argument to addi or addis. Fixes PR18316.

I don't have a small stable test case.

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205823 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r204155:

------------------------------------------------------------------------
r204155 | wschmidt | 2014-03-18 10:32:50 -0400 (Tue, 18 Mar 2014) | 16 lines

Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0.

When converting a signed 32-bit integer to double-precision floating point on
hardware without a lfiwax instruction, we have to instead use a lfd followed
by fcfid.  We were erroneously offsetting the address by 4 bytes in
preparation for either a lfiwax or lfiwzx when generating the lfd.  This fixes
that silly error.

This was not caught in the test suite since the conversion tests were run with
-mcpu=pwr7, which implies availability of lfiwax.  I've added another test
case for older hardware that checks the code we expect in the absence of
lfiwax and other flavors of fcfid.  There are fewer tests in this test case
because we punt to DAG selection in more cases on older hardware.  (We must
generate complex fiddly sequences in those cases, and there is marginal
benefit in duplicating that logic in fast-isel.)

------------------------------------------------------------------------

git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_34@205824 91177308-0d34-0410-b5e6-96231b3b80d8