Go to file
Chandler Carruth 4bd8f66ed9 Revert the business end of r164636 and try again. I'll come in again. ;]
This should really, really fix PR13916. For real this time. The
underlying bug is... a bit more subtle than I had imagined.

The setup is a code pattern that leads to an @llvm.memcpy call with two
equal pointers to an alloca in the source and dest. Now, not any pattern
will do. The alloca needs to be formed just so, and both pointers should
be wrapped in different bitcasts etc. When this precise pattern hits,
a funny sequence of events transpires. First, we correctly detect the
potential for overlap, and correctly optimize the memcpy. The first
time. However, we do simplify the set of users of the alloca, and that
causes us to run the alloca back through the SROA pass in case there are
knock-on simplifications. At this point, a curious thing has happened.
If we happen to have an i8 alloca, we have direct i8 pointer values. So
we don't bother creating a cast, we rewrite the arguments to the memcpy
to dircetly refer to the alloca.

Now, in an unrelated area of the pass, we have clever logic which
ensures that when visiting each User of a particular pointer derived
from an alloca, we only visit that User once, and directly inspect all
of its operands which refer to that particular pointer value. However,
the mechanism used to detect memcpy's with the potential to overlap
relied upon getting visited once per *Use*, not once per *User*. This is
always true *unless* the same exact value is both source and dest. It
turns out that almost nothing actually produces that pattern though.

We can hand craft test cases that more directly test this behavior of
course, and those are included. Also, note that there is a significant
missed optimization here -- we prove in many cases that there is
a non-volatile memcpy call with identical source and dest addresses. We
shouldn't prevent splitting the alloca in that case, and in fact we
should just remove such memcpy calls eagerly. I'll address that in
a subsequent commit.

llvm-svn: 164669
2012-09-26 07:41:40 +00:00
clang Add struct keyword before _Unwind_Context. 2012-09-26 06:35:17 +00:00
clang-tools-extra Fix typo in a comment in lit.cfg 2012-09-12 16:29:37 +00:00
compiler-rt [TSan] fork external symbolizer before starting internal threads 2012-09-25 12:35:47 +00:00
debuginfo-tests Fix this for gdb 7.4. 2012-07-23 19:41:58 +00:00
libclc Add barrier.cl to SOURCES, spotted by Jin Wang. 2012-09-05 18:13:55 +00:00
libcxx Apply the emulated nullptr_t with constexpr. This is an unusual configuration that would take advantage of this. But it has popped up in the wild and does no harm to support it. 2012-09-24 23:36:40 +00:00
libcxxabi Updating email address 2012-09-24 14:27:24 +00:00
lld This patch makes use of recently added relocation reference data. The bulk 2012-09-25 18:22:09 +00:00
lldb Fixed a bug in the path remapper that caused 2012-09-26 01:28:11 +00:00
llvm Revert the business end of r164636 and try again. I'll come in again. ;] 2012-09-26 07:41:40 +00:00
polly Bailout if libpluto finds no schedule 2012-09-21 16:24:13 +00:00