From: Eli Friedman Date: Tue, 22 Mar 2011 20:49:53 +0000 (+0000) Subject: A bit more analysis of a memset-related README entry. X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=97ab5803df4a549db9cd93e80426971e64562672;p=oota-llvm.git A bit more analysis of a memset-related README entry. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128107 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/lib/Target/README.txt b/lib/Target/README.txt index 63f1f79962b..33941f451a0 100644 --- 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. //===---------------------------------------------------------------------===//