Re: question about rtl loop-iv analysis

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

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