[llvm-commits] [llvm] r128107 - /llvm/trunk/lib/Target/README.txt

[Nick Lewycky]

Eli Friedman wrote:
> Author: efriedma
> Date: Tue Mar 22 15:49:53 2011
> New Revision: 128107
>
> URL: http://llvm.org/viewvc/llvm-project?rev=128107&view=rev
> Log:
> A bit more analysis of a memset-related README entry.
>
>
> Modified:
>      llvm/trunk/lib/Target/README.txt
>
> Modified: llvm/trunk/lib/Target/README.txt
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/README.txt?rev=128107&r1=128106&r2=128107&view=diff
> ==============================================================================
> --- llvm/trunk/lib/Target/README.txt (original)
> +++ llvm/trunk/lib/Target/README.txt Tue Mar 22 15:49:53 2011
> @@ -2074,11 +2074,12 @@
>   }
>
>   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.

Yes, this is:

   http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-January/037495.html

which is still unsolved, even though I've added numerous optimizations 
to SCEV since that posting.

Nick

>
>   //===---------------------------------------------------------------------===//
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>