df.c and partial writes/REG_EQUAL notes

[Daniel Berlin]

On Tuesday, September 25, 2001, at 10:16  AM, Jan Hubicka wrote:

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

Don't worry about the interactions, as the register allocator branch
A. has it's own version of df.c
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.

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.


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