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

[Eli Friedman]

On Tue, Mar 22, 2011 at 6:30 PM, Nick Lewycky <nicholas at mxc.ca> wrote:
> 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.

Mmm... at least for
test/Transforms/IndVarSimplify/signed-trip-count.ll , it looks like
the issue has to do with the value of the calls to
getMaxBackedgeTakenCount() in ScalarEvolution::getSignedRange and
ScalarEvolution::getUnsignedRange.  Before the loop exit condition is
rewritten, SCEV returns "2147483646"; after, it returns "(-1 + (zext
i32 %n to i64))".  Not surprisingly, this completely screws up the
range analysis.

-Eli