Zdenek Dvorak wrote:
> Hello,
>
>
>> And finally at the stage of rtl unrolling it looks like this:
>> [6] r186 = r2 + C;
>> r318 = r186 + 160;
>> loop:
>> r186 = r186 + 16
>> if (r186 != r318) then goto loop else exit
>>
>> Then, in loop-unroll.c we call iv_number_of_iterations, which eventually
>> calls iv_analyze_biv (with r258/r186), which in turn calls
>> latch_dominating_def.
>> There, when processing the vectorized case, it encounters the def in the
>> loop ('r186+16'), and then the def outside the loop ('r2+C'), at which
>> point it fails cause it found two defs (and so we get that this is not a
>> simple iv, and not a simple loop, and unrolling fails: "Unable to prove
>> that the loop iterates constant times").
>> When processing the unvectorized case, we also first encounter the def in
>> the loop ('r258+16'), and then the def outside the loop ('0'), but this def
>> succeeds the test "if (!bitmapset (bb_info->out,....))", and so we don't
>> fail when we encounter the second def, and all is well.
>>
>> So one question I have is what is that bitmap exactly, and why does loop
>> [6] fail rtl iv-analysis?
>>
>
> the bitmap bb_info->out should contain reaching definitions at the end
> of the latch block; so the definition of r186 outside of the loop
> should not be contained in it. This seems to be a dataflow analysis
> problem.
>
> Zdenek
>
It could be, but it is hard to see how. There is nothing magic about
the code, i goes over the set of blocks looking for defs and that is
what it uses. Each call to df_set_blocks resets the table of defs that
can be considered.
In particular, you need to first verify that you are passing exactly the
correct set of blocks to df_set_blocks.
Kenny
