Hal Finkel b6d0d6b263 [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: 214481		2014-08-01 05:20:41 +00:00
clang	[modules] Remove IRGen special case for emitting implicit special members if	2014-08-01 01:56:39 +00:00
clang-tools-extra	[clang-tidy] Add a checker for code that looks like a delegate constructors but doesn't delegate.	2014-07-31 09:58:52 +00:00
compiler-rt	[Sanitizer] Don't try to parse unspecified suppressions file	2014-07-31 19:06:47 +00:00
debuginfo-tests	relax testcase for LLDB output format compatibility.	2014-03-19 23:06:18 +00:00
libclc	Implement sin builtin for float types	2014-07-23 15:16:21 +00:00
libcxx	Update linux test results file	2014-08-01 01:59:09 +00:00
libcxxabi	libcxxabi cmake: Use HandleLLVMOptions.cmake, don't manually add -std=c++11.	2014-07-16 23:53:37 +00:00
lld	[PECOFF] Fix section header.	2014-07-31 22:40:35 +00:00
lldb	Change the encoding of the Triple string exchanged across GDB-RSP	2014-08-01 05:12:23 +00:00
llvm	[PowerPC] Generate unaligned vector loads using intrinsics instead of regular loads	2014-08-01 05:20:41 +00:00
openmp	CMake: remove duplicated source file from list	2014-06-02 13:09:24 +00:00
polly	[Refactor] Remove unecessary check and function	2014-07-31 21:34:32 +00:00