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]

Re: df.c and partial writes/REG_EQUAL notes


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

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

What exactly do you mean by global liveness?
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"
> 
> 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..

Honza
> 
> 
> >  Would be the approach described good
> >enought?
> 
> >Alternativly we may want to make dataflow more smart and realize that 
> >insn 2 does not
> >use value of insn 1, but insn 3 uses both, but I am not quite sure it 
> >is wortwhile,
> >as pass who wants to be aware of this should also know that insn 1 
> >can't be placed
> >after insn 2, even when the insn 2 does not use the value nor does kill 
> >the value
> >defined by insn 1.
> >
> >What do you think is the most suitable behaviour?
> >
> >Problem 2
> >=========
> >
> >Another problem I've run into are the REG_EQUAL/EQUIV notes.  Currently 
> >dataflow
> >ignores them, but attempts to update them when register is replaced, 
> >but this is quite
> >wrong, as the insn may not mention the register in the pattern, but 
> >still may contain
> >it in the REG_EQUIV note.  This is common in libcall sequences and 
> >similar stuff.
> >
> >I've added an option to build dataflow with REG_EQUIV/EQUAL notes 
> >reprezented as
> >ordinally uses.
> >
> >Does that sound sane?
> >With my new "flags" field I've introduced for the problem 1, I can even 
> >mark them,
> >so the eventual passes may ignore them in some cases - does that make 
> >sense for
> >register allocator (as it is probably only one who will do so).
> >
> >I am attaching the patch as well as the webizer code, both kind of 
> >work-in-progress.
> >
> >Honza
> >


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