[llvm-commits] [llvm] r75252 - in /llvm/trunk: include/llvm/Analysis/ScalarEvolution.h include/llvm/Analysis/ScalarEvolutionExpressions.h lib/Analysis/ScalarEvolution.cpp test/Transforms/IndVarSimplify/iv-sext.ll

[Nick Lewycky]

2009/7/10 Nick Lewycky <nlewycky at google.com>

> 2009/7/10 Dan Gohman <gohman at apple.com>
>
>> Author: djg
>> Date: Fri Jul 10 11:42:52 2009
>> New Revision: 75252
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=75252&view=rev
>> Log:
>> Generalize ScalarEvolution's cast-folding code to support more kinds
>> of loops. Add several new functions to for working with ScalarEvolution's
>> add-hoc value-range analysis functionality.
>
>
> Dan, this looks great! Does this kill off LoopVR?
>
> Why does isKnownPositive(Step) control whether the range should be
> considered signed or unsigned? You're already considering it 'signed' just
> by asking the question; an unsigned value is always positive :-)
>
> The intuition here is that getSignedRange and getUnsignedRange could be
> merged by checking for the SLT, SGT and ULE cases all in one implementation
> which in turn leads to collapsing of cases in a lot of code. (Oh, and the
> SCEVUnknown code could do both types of computation and just take the
> smaller of the two resulting ranges.)
>

I realized a few minutes after I sent this that it won't collapse too much
code because ConstantRange::getSignedMin and ConstantRange::getUnsignedMax
will return different values sometimes. So trying to merge getSignedRange
and getUnsignedRange may not be worth pursuing, especially if the code is
working correctly as-is. :-)

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20090710/e061d83e/attachment.html>