Merging r196168:

------------------------------------------------------------------------
r196168 | rafael.espindola | 2013-12-02 18:04:51 -0500 (Mon, 02 Dec 2013) | 2 lines

Convert two char* that are only ever used as booleans to bool.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205764 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r196987:

------------------------------------------------------------------------
r196987 | rafael.espindola | 2013-12-10 19:09:06 -0500 (Tue, 10 Dec 2013) | 2 lines

Move PPC's getDataLayoutString out of line and document it better.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205765 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r197572:

------------------------------------------------------------------------
r197572 | rafael.espindola | 2013-12-18 09:35:37 -0500 (Wed, 18 Dec 2013) | 6 lines

One ppc32-darwin, a i64 inside a structure can have 32 bit alignment.

Thanks for Iain Sandoe for testing this with the original gcc.

Clang was already getting this right.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205766 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r197574:

------------------------------------------------------------------------
r197574 | rafael.espindola | 2013-12-18 10:06:25 -0500 (Wed, 18 Dec 2013) | 8 lines

Fix f64 and f128 for ppc-darwin.

This patch adds -f64:32:64 to 32 bit ppc darwin since a f64 inside a
structure are only 32 bit aligned.

The patch also drop -f128:64:128 from all ppc darwin, since f128 is
128 bit aligned.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205767 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r198744:

------------------------------------------------------------------------
r198744 | iain | 2014-01-08 05:22:54 -0500 (Wed, 08 Jan 2014) | 8 lines

[patch] Adjust behavior of FDE cross-section relocs for targets that don't support abs-differences.

Modern versions of OSX/Darwin's ld (ld64 > 97.17) have an optimisation present that allows the back end to omit relocations (and replace them with an absolute difference) for FDE some text section refs.

This patch allows a backend to opt-in to this behaviour by setting "DwarfFDESymbolsUseAbsDiff".  At present, this is only enabled for modern x86 OSX ports.

test changes by David Fang.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205768 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r198863:

------------------------------------------------------------------------
r198863 | stpworld | 2014-01-09 07:26:12 -0500 (Thu, 09 Jan 2014) | 6 lines

Fixed old typo in ScalarEvolution, that caused wrong SCEVs zext operation.
Detailed description is here:
http://llvm.org/bugs/show_bug.cgi?id=18000#c16

For participation in bugfix process special thanks to David Wiberg.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205794 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r201104:

------------------------------------------------------------------------
r201104 | chandlerc | 2014-02-10 14:39:35 -0500 (Mon, 10 Feb 2014) | 26 lines

[LPM] A terribly simple fix to a terribly complex bug: PR18773.

The crux of the issue is that LCSSA doesn't preserve stateful alias
analyses. Before r200067, LICM didn't cause LCSSA to run in the LTO pass
manager, where LICM runs essentially without any of the other loop
passes. As a consequence the globalmodref-aa pass run before that loop
pass manager was able to survive the loop pass manager and be used by
DSE to eliminate stores in the function called from the loop body in
Adobe-C++/loop_unroll (and similar patterns in other benchmarks).

When LICM was taught to preserve LCSSA it had to require it as well.
This caused it to be run in the loop pass manager and because it did not
preserve AA, the stateful AA was lost. Most of LLVM's AA isn't stateful
and so this didn't manifest in most cases. Also, in most cases LCSSA was
already running, and so there was no interesting change.

The real kicker is that LCSSA by its definition (injecting PHI nodes
only) trivially preserves AA! All we need to do is mark it, and then
everything goes back to working as intended. It probably was blocking
some other weird cases of stateful AA but the only one I have is
a 1000-line IR test case from loop_unroll, so I don't really have a good
test case here.

Hopefully this fixes the regressions on performance that have been seen
since that revision.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205795 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r202273:

------------------------------------------------------------------------
r202273 | atrick | 2014-02-26 11:31:56 -0500 (Wed, 26 Feb 2014) | 4 lines

Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use.

Patch by Michael Zolotukhin!

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205796 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r203719:

------------------------------------------------------------------------
r203719 | mzolotukhin | 2014-03-12 17:31:05 -0400 (Wed, 12 Mar 2014) | 4 lines

PR17473:
Don't normalize an expression during postinc transformation unless it's
invertible.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205797 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r203725:

------------------------------------------------------------------------
r203725 | rafael.espindola | 2014-03-12 18:03:43 -0400 (Wed, 12 Mar 2014) | 2 lines

This test need the X86 backend, move it to the X86 sub directory.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205798 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r200201:

------------------------------------------------------------------------
r200201 | stpworld | 2014-01-27 04:18:31 -0500 (Mon, 27 Jan 2014) | 31 lines

Fix for PR18102.

Issue outcomes from DAGCombiner::MergeConsequtiveStores, more precisely from
mem-ops sequence sorting.

Consider, how MergeConsequtiveStores works for next example:

store i8 1, a[0]
store i8 2, a[1]
store i8 3, a[1]   ; a[1] again.
return   ; DAG starts here

1. Method will collect all the 3 stores.
2. It sorts them by distance from the base pointer (farthest with highest
index).
3. It takes first consecutive non-overlapping stores and (if possible) replaces
them with a single store instruction.

The point is, we can't determine here which 'store' instruction
would be the second after sorting ('store 2' or 'store 3').
It happens that 'store 3' would be the second, and 'store 2' would be the third.

So after merging we have the next result:

store i16 (1 | 3 << 8), base   ; is a[0] but bit-casted to i16
store i8 2, a[1]

So actually we swapped 'store 3' and 'store 2' and got wrong contents in a[1].

Fix: In sort routine just also take into account mem-op sequence number.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205806 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r200202:

------------------------------------------------------------------------
r200202 | stpworld | 2014-01-27 04:43:10 -0500 (Mon, 27 Jan 2014) | 2 lines

Additional fix for 200201: due to dependence on bitwidth test was moved to X86 directory.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205807 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r205738:

------------------------------------------------------------------------
r205738 | atrick | 2014-04-07 17:29:22 -0400 (Mon, 07 Apr 2014) | 16 lines

Put a limit on ScheduleDAGSDNodes::ClusterNeighboringLoads to avoid blowing up compile time.

Fixes PR16365 - Extremely slow compilation in -O1 and -O2.

The SD scheduler has a quadratic implementation of load clustering
which absolutely blows up compile time for large blocks with constant
pool loads. The MI scheduler has a better implementation of load
clustering. However, we have not done the work yet to completely
eliminate the SD scheduler. Some benchmarks still seem to benefit from
early load clustering, although maybe by chance.

As an intermediate term fix, I just put a nice limit on the number of
DAG users to search before finding a match. With this limit there are no
binary differences in the LLVM test suite, and the PR16365 test case
does not suffer any compile time impact from this routine.

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

git-svn-id: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205808 91177308-0d34-0410-b5e6-96231b3b80d8
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: http://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: http://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: http://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: http://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: http://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: http://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: http://llvm.org/svn/llvm-project/llvm/branches/release_34@205822 91177308-0d34-0410-b5e6-96231b3b80d8