A bit more analysis of a memset-related README entry.

[oota-llvm.git] / lib / Target / README.txt

diff --git a/lib/Target/README.txt b/lib/Target/README.txt
index 63f1f79962bf443ab6a634d8f1b36f0303412d58..33941f451a0cab6389313149c34c8f9d1ea24155 100644 (file)
--- a/lib/Target/README.txt
+++ b/lib/Target/README.txt
@@ -2074,11 +2074,12 @@ for.end:                                          ; preds = %entry
 }
 
 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.
+the two memset's together.
 
-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'.
+The issue with the addition only occurs in 64-bit mode, and appears to be at
+least partially caused by Scalar Evolution not keeping its cache updated: it
+returns the "wrong" result immediately after indvars runs, but figures out the
+expected result if it is run from scratch on IR resulting from running indvars.
 
 //===---------------------------------------------------------------------===//