Re: df.c and partial writes/REG_EQUAL notes

[Jan Hubicka <jh@suse.cz>]

>   In message <20010925161602.C13734@atrey.karlin.mff.cuni.cz>you write:
>   > 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.
> Don't bother.  SSA will do this for you in a much more sane way and will
> probably be faster and generate better code anyway.

Hmm, I understand that you may get the renaming of pseudos as side effect
of SSA/deSSA converison, but why it will be faster/generate better code?

>   > Will currently use 5 increments, but if the various copies of A are
>   > split, the CSE/combine takes care to construct multiple moves.
> Err, so what is really looks like you want to do is splitting variables
> during unrolling.  I recommend you look at Morgan/Muchnik as they discuss
> variable expansion in this context.

I did.  What I wanted is to do in general - not only for loops unrolled by gcc.
> 
> 
>   > Problem 1
>   > =========
>   > 
>   > I've run into problems with dataflow analyzis and partial writes.  For inst
>   > ance 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,
> Right.  Review the movxx section in the Machine Descriptions part of the
> manual.  Quoting:
> 
> @cindex @code{mov@var{m}} instruction pattern
> @item @samp{mov@var{m}}
> Here @var{m} stands for a two-letter machine mode name, in lower case.
> This instruction pattern moves data with that machine mode from operand
> 1 to operand 0.  For example, @samp{movsi} moves full-word data.
> 
> If operand 0 is a @code{subreg} with mode @var{m} of a register whose
> own mode is wider than @var{m}, the effect of this instruction is
> to store the specified value in the part of the register that corresponds
> to mode @var{m}.  The effect on the rest of the register is undefined.
> 
> Based on that I believe there should be no dependency since insn #2
> leaves the rest of the DI register undefined.

Then the documentation is wrong - most ports use subreg in a way that it
clobbers the specified word only.

Honza