This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: question about rtl loop-iv analysis
On Tue, 28 Aug 2007, Kenneth Zadeck wrote:
> >>>> 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
> >>>>
> >
> > 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.
I don't think that's the case above for r186.
Apart from that I agree that in the case of conditional defs multiple ones
might reach a use. I disagree for partial defs, if one dominates the
other. For most cases (except register allocation) a partial def is just
a complete killing def, which happens to leave some contents unchanged (by
conceptually copying that part from what was in there before, hence the
usual read-mod-write dependency from a partial def which generates also a
use). But the use doesn't care for this, for all it knows that def is the
one changing the contents, hence a use-def chain should not contain a def
dominating other defs (partial or not). The relationship between both
defs will be described by the use-def chain hanging off the implicit use
generated by the partial def.
E.g. in this example (using my old hopefully understandable notation), if
p1 is a DImode pseudo:
1 p1+0:SI <- bla
2 p1+4:SI <- blubb
3 use <- p1:DI
insn 3 should only see def 2 in it's chain. That it also is influenced by
the def 1 will be captured by the implicit use of p1 in insn 2. I.e. not
different to
1 p1 <- bla
2 p1 <- p1 + blubb
3 use <- p1
Exact partial defs should only (and do) matter for register allocation.
That's one of the reasons why (some years ago for new-ra) I exposed
real partial defs of subregs from the df framework only for the register
allocator, but not for general code.
Ciao,
Michael.