[LLVMdev] scalar-evolution + indvars fail to get the loop trip count?
Sheng Zhou
zhousheng at autoesl.com
Tue Dec 9 01:43:39 PST 2008
>
>
> Having the final .ll file doesn't help debug this. If you run opt
> -analyze -scalar-evolution on the .ll you pasted, it will correctly
> print out the loop trip count.
>
> I've modified llvm-gcc to remove all the passes after indvars.
>
>
I updated my llvm and now it works.
>> > Surely the loop trip count is 256, but the Loop::getTripCount() will
>> > return NULL.
>> > This is due to the exit condition:
>> >
>> > %tmp16 = icmp slt i32 %tmp13, 0 ; <i1> [#uses=1]
>> >
>> > pass indvars should transform it into a canonical exit condtion EQ or
>> > NE, but as scalarevolution returned NonComputedItCount, it failed to do
>> > that.
>> >
>> > In pass ScalarEvolution three algorithms failed to compute the trip count:
>> >
>> > 1. In SCEVAddRecExpr::getNumIterationsInRange(), as the loop stride is
>> > negative, the exit value expression will be zero: (Here A is the stride
>> > value)
>> >
>> > // The exit value should be (End+A)/A.
>> > APInt ExitVal = (End + A).udiv(A);
>> > ConstantInt *ExitValue = ConstantInt::get(ExitVal);
>>
>
> Yes, that code path will fail for this example.
>
Why not improve this? We can change it into :
APInt ExitVal = (End + A).sdiv(A);
Surely we should take care of the range of this expression, maybe need extend the bitwidth of (End+A)
>
>> > 2. In Line 1953, the switch-case computes the trip count due to
>> > different Cond code.
>> > But in this case, as it exits on true, the slt is converted to sge,
>> > not switch-case for this condtion.
>>
>
> Not sure what you mean. The problem is that HowManyLessThans was
> refusing to work on a signed less-than or equal to, even in the trivial
> case (just because I haven't yet gotten around to working on the complex
> case of a non-unit stride).
>
>
Make sense.
>> > 3. As the loop count is over 100, the Brute-Force algorithm also doent work
>> >
>> > Can we improve this?
>>
>
> Done. Committed in r60748.
>
Thanks for your quick work, Nick :-)
More information about the llvm-dev
mailing list