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


Hi,

On Wed, 29 Aug 2007, Bernd Schmidt wrote:

> > 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.
> 
> I completely agree, and I've tried very hard to argue that with Kenneth 
> last year when I spotted this kind of bogosity in the dataflow code, but 

I initially implemented giving out partial defs in df.c on the new-ra 
branch because I needed it for precise subreg register allocation.  
Before that df.c was doing simply the read-mod-write scheme (i.e. 
generating a use-ref and a def-ref for each partial write).  That code 
later also landed in mainline, with new-ra being removed somewhat later, 
but not the df.c changes (but they were still conditional on some flag, 
that you really wanted those partial defs, for exclusive use of a reg 
allocator).  I believe that code was ported forward in all later df*.c 
rewrites and extensions, and hence still is there.

If that is true, then I can say for sure that I definitely never intended 
to expose partial defs without use-refs to the outside except for very 
constrained use cases, namely register allocation, or generally any pass 
which might be interested in exact subreg life times _and_ is prepared to 
handle them, which most usual code is not, simply because it doesn't 
matter for them.  Because if they aren't prepared to handle them they will 
become confused as to what is and what is not a "complete" definition (in 
the sense that between that def and the use in question no contents from 
before that bordering def remain; in fact they have no concept of that) 
and be surprised by uses reached by two defs where one dominates the other 
(e.g. because both are in the same basic block).

</history>

If df*.c is now doing that for all it's callers I'm pretty sure that just 
started as an artifact and later transformed into the normal way of doing 
things.  It would be wrong nevertheless.


Ciao,
Michael.


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