This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]