Re: df.c and partial writes/REG_EQUAL notes

[Michael Matz <matzmich@cs.tu-berlin.de>]

Hi,

Sorry for being late again:

On Tue, 25 Sep 2001, Jan Hubicka wrote:

> > Don't worry about the interactions, as the register allocator branch
> > A. has it's own version of df.c
>
> But once you will attempt to merge allocator in, you probably would not want
> to have df1.c and df2.c right?

Right.  But I'm nearly sure, that I'll not use df.c at all.  One reason
is, that the allocator also must collect the constraints for all reg
references (or better said for all operands), which would need a second
pass over all insns if I would use df.* for collecting the references
itself.  Note that even currently df.* is only used for collecting all
register references by the allocator.  Esp. it's not used for building the
use/def-chains.  (But, Daniels rematerialization uses the chains from
df.*)

If you want to know how I dealt with subregs and webs, look at ra.c, which
contains a fairly complete implementation of creating webs in a lazy
manner (although tailored to register allocation, i.e. also noting
conflicts and other things), including subwebs for subreg references.
The data structures there are not yet in their final state, but still.
(<self-praise> Btw. it's faster than df.* building of use/def chains on
CFG's of measurable size and can be relatively easy made to work
incrementally </self-praise>)

> > B. only uses df.c for reg defs and uses.  All dataflow is done without
> > df.c routines, because Michael doesn't want to use global liveness.
>
> As I've described, it misses one use at least, that should affect the
> reg-alloc branch too.

No, as described I don't rely on df.* to build any connections between
defs and uses.

> What exactly do you mean by global liveness?

I think he meant the usage of the DU_CHAIN or UD_CHAIN flags and
additionally bb->global_live_at_{start,end}, which also isn't used by
ra.c.

> If you do some extra analyzis, you should make as much of the as
> possible available to other passes - we already do have too many stuff
> doing analyzis "just for myself"

Right, and generally I agree.  From my p.o.v. the regalloc has a special
usage pattern of register references and their connection, which justifies
an own implementation.  But of course I may be biased ;-)

> > I.E. It only cares about noticing all of the reg defs and uses, it
> > doesn't care whether df.c really knows what they do.
> My web code too..

No, you rely on df.* to build the chains, which is exactly where you saw
the problems.  I suppose this is because initially Michael (Hayes) wrote
df.* to work only on REGs (i.e. recursing into SUBREGs when noting
references), and for that the chain builder worked.  For the allocator I
hacked more or less around it, and also offered the SUBREG references to
outside code, without actually making changes to the chain builder.  I.e.
if df.c compiles with HANDLE_SUBREG defined, it may very well be, that
that part of df.c gets everything wrong, if presented with df-tables which
contain subreg references.


Ciao,
Michael.