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.
>>>
>>>       
>> 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.
>>     
>
> regardless of the set of blocks considered, there is no way how both the
> definition outside of the loop and the definition inside the loop could
> both be reaching definitions at the same point in the program.
>
> Zdenek
>   
sure it can.  if the def is not a killing def, i.e. the def is a partial
or conditional, then the prior defs reach right in.

kenny

Reply via email to