[llvm-commits] [llvm] r49928 - /llvm/trunk/lib/Analysis/ScalarEvolution.cpp
Chris Lattner
clattner at apple.com
Sat Apr 19 17:57:32 PDT 2008
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.
> 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?
-Chris
More information about the llvm-commits
mailing list