df.c and partial writes/REG_EQUAL notes

[Jan Hubicka]

Hi,
yesterday I wanted to make myself familiar with the dataflow module and write
simple code to construct webs early and split each pseudo consisting of multiple
webs to assist CSE and other optimizations.  What I am shooting for is to replace
some of logic of unroll.c to make it more rewritable for CFG.  For instance code like
*a++=0;
*a++=0;
*a++=0;
*a++=0;
*a++=0;
Will currently use 5 increments, but if the various copies of A are split, the
CSE/combine takes care to construct multiple moves.

Problem 1
=========

I've run into problems with dataflow analyzis and partial writes.  For instance following
code:

1: (set (reg:DI x) (const_int 0))

2: (set (subreg:SI (reg:DI x) 0) (const_int 1))

3: (use somewhere reg:DI x)

As currently impleemnted in df.c, there will be no depdendancy between insn 1 and insn 3,
as the store in insn 2 is believed to kill whole value of X.
The semantic of insn 2 is to overwruite just first word of the value so the insn 3 uses
values of both instructions.

I am attaching an work-in-progress patch, that changes the behaviour to represent the
depdendancy between insn 1 and insn 2 and mark the definition in insn 2 as read/write,
as well as the use in insn 2, so my web code can realize the fact that the register
must be equal and I can merge webs for X in insns 1-2 and X in insns 2-3 otherwise
disjunct.

In same way I get read/write for strict_low_part

There are number of hacks around the code, as I understand designed to cooperate somehow
with register allocator, but I am not 100% sure how.  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