Re: df.c and partial writes/REG_EQUAL notes

[law at redhat dot com]

  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.

  > What I am shootingfor is to replace some of logic of unroll.c to make it
  > more rewritable for CFG.
Having the unroller using the CFG would definitely be an improvement. 

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


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


  > as the store in insn 2 is believed to kill whole value of X.
As it should.

  > The semantic of insn 2 is to overwruite just first word of the value so
  > the insn 3 uses values of both instructions.
No.  See above.


  > 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. 
Yes.  This is an issue.

jeff