[llvm-commits] [llvm] r49928 - /llvm/trunk/lib/Analysis/ScalarEvolution.cpp

[Dale Johannesen]

On Apr 19, 2008, at 5:57 PM, Chris Lattner wrote:

>
> On Apr 19, 2008, at 5:52 PM, Dale Johannesen wrote:
>
>>
>> On Apr 19, 2008, at 5:38 PM, Chris Lattner wrote:
>>> On Apr 19, 2008, at 5:32 PM, Dale Johannesen wrote:
>>>>
>>>> On Apr 19, 2008, at 5:22 PM, Nick Lewycky wrote:
>>>>
>>> Ah ok, good catch :).  I don't think howfartozero is safe to use in
>>> any case.  If it were, we could just use it in the ULT case too,
>>> right?
>>
>> If you continue with the thread you see Nick has that concern also.
>> It is true that the SCEV expression isn't right in that case if the
>> loop is never supposed to be executed, but so far every case I've  
>> seen
>> has a guard test outside the loop proper, so I believe everything
>> works (the test I checked in exercises this case).
>
> This may be true for while/for loops, but isn't true for do+while  
> loops.
>
> do {
>   ...
> } while (cond);
>
> Has no dominating check.

But those are not executed 0 times, so the failing case can't arise.   
It works in practice, too.

>> Another possibility is to remove the UGT case entirely, which was my
>> first suggestion.  If you do that the preheader in my test is 2
>> instructions, compared to 4 for what's checked in now and 7 for  
>> Nick's
>> alternative.
>> I don't imagine that's a win across the board, but I suspect simple
>> loops like this are more common than the more complicated ones where
>> this optimization is a winner.....
>
> If we are currently producing incorrect code for the UGT case, I'd be
> strongly in favor of disabling it entirely.  This turns a
> miscompilation bug into a missed optimization bug.  Seem reasonable
> Nicholas?