This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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
> >