summaryrefslogtreecommitdiff
path: root/lib/Target/README.txt
diff options
context:
space:
mode:
authorChris Lattner <sabre@nondot.org>2011-01-16 06:39:44 +0000
committerChris Lattner <sabre@nondot.org>2011-01-16 06:39:44 +0000
commitb0daffc609f4e42fe81d4da641f7a9dc947bad53 (patch)
tree2e8a109b37daad2dffc7f0521031f2450cd82940 /lib/Target/README.txt
parent7e9b427c879ae32b72fd24aeaf011e87e5692fd7 (diff)
downloadllvm-b0daffc609f4e42fe81d4da641f7a9dc947bad53.tar.gz
llvm-b0daffc609f4e42fe81d4da641f7a9dc947bad53.tar.bz2
llvm-b0daffc609f4e42fe81d4da641f7a9dc947bad53.tar.xz
add some commentary
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123572 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/README.txt')
-rw-r--r--lib/Target/README.txt15
1 files changed, 14 insertions, 1 deletions
diff --git a/lib/Target/README.txt b/lib/Target/README.txt
index 8039790606..6ba0d745f6 100644
--- a/lib/Target/README.txt
+++ b/lib/Target/README.txt
@@ -2155,8 +2155,12 @@ _ZNSt12_Vector_baseIiSaIiEEC2EmRKS0_.exit.i.i: ; preds = %cond.true.i.i.i.i
br label %_ZNSt6vectorIiSaIiEEC1EmRKiRKS0_.exit
This is just the handling the construction of the vector. Most surprising here
-is the fact that all three null stores in %entry are dead, but not eliminated.
+is the fact that all three null stores in %entry are dead (because we do no
+cross-block DSE).
+
Also surprising is that %conv isn't simplified to 0 in %....exit.thread.i.i.
+This is a because the client of LazyValueInfo doesn't simplify all instruction
+operands, just selected ones.
//===---------------------------------------------------------------------===//
@@ -2192,6 +2196,9 @@ This shouldn't need the ((zext (%n - 1)) + 1) game, and it should ideally fold
the two memset's together. The issue with %n seems to stem from poor handling
of the original loop.
+To simplify this, we need SCEV to know that "n != 0" because of the dominating
+conditional. That would turn the second memset into a simple memset of 'n'.
+
//===---------------------------------------------------------------------===//
clang -O3 -fno-exceptions currently compiles this code:
@@ -2211,6 +2218,12 @@ S is only 6 bytes, but each element is 8 byte-aligned. We generate a loop and
4 stores on each iteration. If the struct were 8 bytes, this gets turned into
a memset.
+In order to handle this we have to:
+ A) Teach clang to generate metadata for memsets of structs that have holes in
+ them.
+ B) Teach clang to use such a memset for zero init of this struct (since it has
+ a hole), instead of doing elementwise zeroing.
+
//===---------------------------------------------------------------------===//
clang -O3 currently compiles this code: