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.
> >
> 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.

that obviously is not the case here, though.  Do you (or someone else
responsible for df) have time to have a look at this problem?
Otherwise, we may discuss it forever, but we will not get anywhere.

Zdenek