[dataflow] PATCH removal of more of flow.c.

[Joern RENNECKE]

Kenneth Zadeck wrote:

>Paolo Bonzini wrote:
>  
>
>>>Index: struct-equiv.c
>>>===================================================================
>>>--- struct-equiv.c    (revision 115422)
>>>+++ struct-equiv.c    (working copy)
>>>@@ -989,10 +989,6 @@ bool
>>> struct_equiv_init (int mode, struct equiv_info *info)
>>> {
>>>   if ((info->x_block->flags | info->y_block->flags) & BB_DIRTY)
>>>-    update_life_info_in_dirty_blocks (UPDATE_LIFE_GLOBAL_RM_NOTES,
>>>-                      (PROP_DEATH_NOTES
>>>-                       | ((mode & CLEANUP_POST_REGSTACK)
>>>-                      ? PROP_POST_REGSTACK : 0)));
>>>   if (!REG_SET_EQUAL_P (DF_LR_OUT (rtl_df, info->x_block),
>>>      
>>>
>I will fix this, as far as I could determine, this was dead code anyway.
>If this is resurrected it will need create it's own copy of df and
>destroy it when it is finished since it cannot rely on persistent
>dataflow info any more.
>  
>
This code was only supposed to be temporarily disabled over Christmas.

>>The first if statement is not removed.
>>
>>Also, it may be worthwhile to put a comment in config/sh/sh.c that its
>>machine dependent reorg pass is looking at LOG_LINKS even though they
>>are all NULL.
>>
>>    
>>
>It is hard to see how this could be correct unless the uses are called
>immediately after combine or scheduling since no other passes even try
>to keep this up to date.
>  
>
machine_dependent_reorg used to run immediately after sched2 (ignoring 
reg-stack,
which does not run on the SH).
It seems some more passes have been wedged in now, I'm don't know if they
make a difference.
That being said, I would welcome a change of this code to something more
solid, as long as we end up with something that works in practice.

The objective is to find constant loads where we can account for all the 
uses
as some sort of function call; if that is the case, we emit a label 
before the load,
and .uses <label> pseudo-ops before the uses of the register.  The 
assembler &
linker can use this information to provide link-time-relaxation, i.e. when
all the calls can be  implemented with the limited-range 
branch-to-subroutine
instruction , the constant load, and usually the constant, can be 
eliminated.
There has also been discussion of extending this scheme to other kinds of
loads and uses, e.g. TLS accesses:
http://gcc.gnu.org/ml/gcc-patches/2003-02/msg01807.html

To formulate this in DF terms, we'd need to solve both RU and RD.
For each potentially eligible definition, we'll have to examine each use
(RU) to verify that we might be able to do without the value or use a 
simpler
version of it by doing link-time relaxation, and that all its 
definitions (RD)
load the same value.

Strictly speaking, we don't need to solve a complete RU problem; we could
restrict the exact tracking of uses as caused by a specific instruction 
to uses that
are actually potential candidates for relaxation, and consider all the 
other uses of
the same register as a single use (we can't get rid of them with 
relaxation, hence it
doesn't matter how many there are exactly and where there are, only if 
there is
none or at least one).
Moreover, only the hard register r0..r14 are of interest, we can't do 
any relaxation
with other registers.
I don't know if formulating such restricted RU problems would fit into 
the DF
infrastructure.

>>.
>>
>>The cleanup sequence then is like this:
>>- cleanup the now dead code in the SH back-end.
>>    
>>
Huh?  Which code is now dead?

>Flow is not going quietly.  The last patch has been really hard to track
>down the last side effects.  My best people are fighting an entrenched
>battle even as we speak.
>  
>
This might sound be funny, but it paints a wrong picture.  Flow is not 
the enemy.
It's more like an old employee reaching retirement, and you find out 
that (s)he's
been so entrenched in the company infrastructure you have to hire five 
new people
to cover all his/her responsibilities.