Creating release candidate rc2 from release_350 branch
llvm-svn: 215080
llvm-svn: 215078
llvm-svn: 215077
llvm-svn: 215076
llvm-svn: 215075
llvm-svn: 215074
llvm-svn: 215073
llvm-svn: 215070
llvm-svn: 215069
--
SVN tag also included these previous commits:
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:27 2014 +0000
Remove for retagging.
llvm-svn: 215068
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:25 2014 +0000
Remove for retagging.
llvm-svn: 215067
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:23 2014 +0000
Remove for retagging.
llvm-svn: 215066
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:21 2014 +0000
Remove for retagging.
llvm-svn: 215065
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:19 2014 +0000
Remove for retagging.
llvm-svn: 215064
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:18 2014 +0000
Remove for retagging.
llvm-svn: 215063
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:11 2014 +0000
Remove for retagging.
llvm-svn: 215060
Author: Bill Wendling <isanbard@gmail.com>
Date: Thu Aug 07 04:55:09 2014 +0000
Remove for retagging.
llvm-svn: 215059
Author: Bill Wendling <isanbard@gmail.com>
Date: Wed Aug 06 23:28:15 2014 +0000
Creating release candidate rc2 from release_350 branch
llvm-svn: 215042
llvm-svn: 215041
llvm-svn: 215040
llvm-svn: 215039
llvm-svn: 215038
llvm-svn: 215037
llvm-svn: 215034
llvm-svn: 215033
Merging r214481:
------------------------------------------------------------------------
r214481 | hfinkel | 2014-07-31 22:20:41 -0700 (Thu, 31 Jul 2014) | 38 lines
[PowerPC] Generate unaligned vector loads using intrinsics instead of regular loads
Altivec vector loads on PowerPC have an interesting property: They always load
from an aligned address (by rounding down the address actually provided if
necessary). In order to generate an actual unaligned load, you can generate two
load instructions, one with the original address, one offset by one vector
length, and use a special permutation to extract the bytes desired.
When this was originally implemented, I generated these two loads using regular
ISD::LOAD nodes, now marked as aligned. Unfortunately, there is a problem with
this:
The alignment of a load does not contribute to its identity, and SDNodes
are uniqued. So, imagine that we have some unaligned load, L1, that is not
aligned. The routine will create two loads, L1(aligned) and (L1+16)(aligned).
Further imagine that there had already existed a load (L1+16)(unaligned) with
the same chain operand as the load L1. When (L1+16)(aligned) is created as part
of the lowering of L1, this load *is* also the (L1+16)(unaligned) node, just
now marked as aligned (because the new alignment overwrites the old). But the
original users of (L1+16)(unaligned) now get the data intended for the
permutation yielding the data for L1, and (L1+16)(unaligned) no longer exists
to get its own permutation-based expansion. This was PR19991.
A second potential problem has to do with the MMOs on these loads, which can be
used by AA during instruction scheduling to break chain-based dependencies. If
the new "aligned" loads get the MMO from the original unaligned load, this does
not represent the fact that it will load data from below the original address.
Normally, this would not matter, but this load might be combined with another
load pair for a previous vector, and then the dependency on the otherwise-
ignored lower bytes can matter.
To fix both problems, instead of generating the necessary loads using regular
ISD::LOAD instructions, ppc_altivec_lvx intrinsics are used instead. These are
provided with MMOs with a conservative address range.
Unfortunately, I no longer have a failing test case (since PR19991 was
reported, other changes in CodeGen have forced this bug back into hiding it
again). Nevertheless, this should fix the underlying problem.
------------------------------------------------------------------------
llvm-svn: 215058
2 files changed
